R
ric
Franc said:
Not unusual for half_wit...er...half_pint.
Not unusual for half_wit...er...half_pint.
H
half_pint
ric said:
My posts are correct, many modem speed calculation methods
are incorrect as I have demonstrated.
Typically you have nothing to contribute to the subject.
H
half_pint
ric said:
I bet you have them rolling in the isles with wit like that :O|
F
Franc Zabkar
Sorry, but it is clear that you have no idea what goes on in a dial-up
connection. Forget the start and stop bits. Unless you have disabled
error correction, these bits are stripped out and discarded by the
modem. To see that this is indeed the case, just look at my test
results. These test data were obtained by using HyperTerminal to
transmit a plain text file directly between two modems connected via a
short piece of phone cable (a perfect noiseless line).
In a non-EC connection, the two modems transfer raw data including
start and stop bits, as follows.
10 bits 10 bits 10 bits
PC #1 <------> Modem #1 <<-------->> Modem #2 <------> PC #2
DTE DCE DTE
An EC connection (without data compression) works as follows.
10 bits 8 bits 10 bits
PC #1 <------> Modem #1 <<-------->> Modem #2 <------> PC #2
DTE DCE DTE
In the latter case there are no start and stop bits. Instead the data
are grouped into packets (or blocks) of 64, 128, or 256 bytes, plus a
small number (6 or 7?) of additional header bytes. AFAIK, the header
includes sync bytes for setting up the clocking of subsequent data
bytes, and a checksum (CRC) for verifying the integrity of the packet.
When you connect to the Internet, you are using PPP. This protocol
adds quite a lot of overhead, so that the download rate reported by
your browser is a lot less than the actual transfer rate of your
modem. That is, your browser counts only the file data, not file data
*plus* PPP overhead. To see the actual download rate you need an app
such as System Monitor (sysmon.exe) which ships with Win9x. For a
46667bps connection, Sysmon reports a download rate of 5.3KB/s for
compressed files, while my browser may show only 4.8KB/s, say.
- Franc Zabkar
H
half_pint
Franc Zabkar said:
I am sorry I am really not to sure what you are on about,
what have start and stop bits got to do with error correction?
Nothing whatsoever as far as I am concerned.
You will have to explain yourself better as I am not sure
what error correction you are on about.
As far as I can see there is no option to 'disable error
connection' in internet options, you can forget Hyperterminal
because I don't use it (as far as I am aware) and neither does the OP.
So i am not really to sure what you are getting at because when I
look at my modem properties is says 8 data, 1 stop bit and no
parity bit (I presume the start bit is taken for granted).
Because it says this I have to believe what I see and take it
as fact as that is what the modem is doing.
If it was configured otherwise I am sure it would say so.
If you can show me a link which clearly shows that these value
are not used I would like to see it.
As I said your Hyper Terminal experiments are not really relevant
as far as I can see.
The utility I mentioned in this thread shows me receiving data at 6.2KBs
H
half_pint
Actually I now accept that the modems (to modem) may not be using
stop and start bits. However having said that I doubt his problem is
down to the telephone line which is probably capable of transmitting
8 mega bits per second, I mean it would be a bit odd if it was only
managing 0.7% of its capacity, and even odder is several people
miraculously also received a similar degradation?
stop and start bits. However having said that I doubt his problem is
down to the telephone line which is probably capable of transmitting
8 mega bits per second, I mean it would be a bit odd if it was only
managing 0.7% of its capacity, and even odder is several people
miraculously also received a similar degradation?
H
half_pint
half_pint said:
.......mind you if you do have you connection speed set to 57600 bps
then I am probably right :O) as the data rate is limited by this setting
which does use stop and start bits!!....
I have a habit of being right even when I am wrong :O)
I have just set mine to 115200 now.
Incidently the utility I am using shows me receiveing data at 7.3 KBs
which is faster than a 56k modem is alledgedly capable!!
F
Franc Zabkar
Exactly. Yet it is you who has introduced irrelevant start and stop
bits to "explain" modem-to-modem transfer rates. What I am saying is
that the only time modems transfer start and stop bits between each
other is on those very rare occasions they have been unable to
negotiate an error corrected link. At all other times these bits are
discarded.
Modems communicate between each other using an error correction
protocol, either V42 LAPM or MNP 4. They assemble data in blocks or
packets, usually 64, 128, or 256 bytes in size. The receiving modem
checks the integrity of the block by validating a checksum (CRC). If
the CRC does not match, then the receiving modem requests that the
faulty block be retransmitted by the sending modem.
In Win9x, go to My Computer -> Dial-Up Networking -> right click your
ISP -> Properties -> General -> Configure -> Connection -> Advanced.
There is a check box called "Use error control". You also have the
option to "compress data".
IMHO, the only way to get meaningful, reproducible results is to use a
comms app such as HyperTerminal, in the way that I have outlined
above.
What you are seeing is the configuration of your COM port, ie the
*DTE* interface, not the *DCE*. The PC sends data bytes out the COM
port, framed with start and stop bits and optional parity, at a DTE
speed of 115200bps, say. However, the two modems discard these extra
bits when communicating between themselves. You need to learn the
difference between the terms DTE and DCE.
DUN has no idea what transpires between the two modems. Such things
are mostly beyond its control.
They *are* used, but only by the DTE, not the DCE. If you compare the
first two lines of my test results, all should be clear (see the
diagrams below). I suggest you also lurk at comp.dcom.modems for a
while.
On the contrary, it is your arbitrary, uncontrolled Internet based
"testing" which is irrelevant. In my test setup I have control over
*all* variables, namely the connection speed (constant 33600bps), line
quality (perfect), and data type (raw text with no PPP overhead).
There are also no potential issues with network congestion.
That test is pointless from the point of view of this discussion. The
figure of 6.2KBs does not reflect the speed of your connection,
instead it shows how well your modem is able to compress the test
data. You need to monitor the download rates for *incompressible*
data, eg ZIPs.
FWIW, my internal modem can achieve download rates as high as 21KB/s
when tranferring highly compressible data such as some newsgroup
headers.
- Franc Zabkar
F
Franc Zabkar
Think "data compression".
AFAIK, the bandwidth of a voice line (~4KHz) is restricted by the line
card in the telephone exchange, and by regulations. ADSL is another
matter. I don't know much about it as yet, but hopefully that will
change when I switch over during the coming week.
- Franc Zabkar
F
Franc Zabkar
I don't know how to explain this either, but that's the way it is. To
see what transpired during your last dial-up session, you can query
your modem's post-call diagnostics. These can tell you a lot about
your modem's performance, including max/min Tx/Rx speeds, error rates,
line noise, retrains, etc.
See http://808hi.com/56k/diag.asp
My Rockwell chipped modem produces the data below. Notice these
abbreviated data for a good session ...
TX/RX I-Frame count : 17654/21091
TX/RX I-Frame error count : 29/14
TX Rate (Last/Init/Min/Max) : 28800/26400/26400/28800
RX Rate (Last/Init/Min/Max) : 46667/46667/45333/46667
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
Retrains (Issued/Granted/Fast) : 0/0/5
Renegs (Issued/Granted) : 2/0
Retrans per frame/Frames rejected : 1/14
Error control timeouts in TX : 16
Error control NAKs received : 29
Termination Cause : Dte Hangup Command
.... a not so good session ...
TX/RX I-Frame count : 10268/34101
TX/RX I-Frame error count : 15/47
TX Rate (Last/Init/Min/Max) : 28800/26400/26400/28800
RX Rate (Last/Init/Min/Max) : 38667/42667/38667/42667
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
Retrains (Issued/Granted/Fast) : 0/0/0
Renegs (Issued/Granted) : 3/0
Retrans per frame/Frames rejected : 1/47
Error control timeouts in TX : 7
Error control NAKs received : 15
Termination Cause : Dte Hangup Command
.... and a bad session (water in the cable) ...
TX/RX I-Frame count : 784/4482
TX/RX I-Frame error count : 23/211
TX Rate (Last/Init/Min/Max) : 26400/26400/26400/28800
RX Rate (Last/Init/Min/Max) : 38667/44000/33333/44000
Modulation/Protocol/Compression : V.90/LAPM/V.42bis
Retrains (Issued/Granted/Fast) : 0/1/2
Renegs (Issued/Granted) : 12/0
Retrans per frame/Frames rejected : 8/211
Error control timeouts in TX : 16
Error control NAKs received : 23
Termination Cause : Retrain Failed
Notice that the initial CONNECT speed is not a reliable indicator of
modem performance, as modems will speedshift as line conditions
change. Notice also that the modem can tell you the reason for
disconnect. For example, a "Termination Cause" of "Disconnect Frame
Received" indicates that your ISP kicked you off.
- Franc Zabkar
H
half_pint
Franc Zabkar said:
I introduded the stop and start bit because they are relevant
to the comms.
Obviously even if these bits are stripped out by the modem it
has no effect on the overall speed because the modem still
has to wait to receive these bits so it might as well transmit them
because it will have bugger all else to do whilst it is waiting.
You sure about that? what about a 1 byte keystroke?
#
Those obtions are not available on my PC, the boxes are there but
they are inaccessible.
I know the differemce and it says modem properties not DTE so you need
to learn to read what is written.
It don't think it really matters as the comms speed it determinded by the
DTE
speed not the modem.
However you are not testing the right patient so to speak,
you are testing a different patient and assuming the real patient
has the same symptoms you found on the proxy patient.
A rather foolish way to diagnose a problem.
The data I am using is compressed data eg jpegs.
well mine is showing 36KBs but I would rather see what
rate bits are being transmitted at as anything else is pretty meaning less.
H
half_pint
Franc Zabkar said:Think "data compression".
AFAIK, the bandwidth of a voice line (~4KHz) is restricted by the line
card in the telephone exchange, and by regulations. ADSL is another
matter. I don't know much about it as yet, but hopefully that will
change when I switch over during the coming week.
I would imagine any restrictions were simply filters are the exchange.
You appear to have snipped out the bit which proves I was right all along?
G
Gary D.
I previously suffered with an almost identical problem, although apart
from slow connection speeds my main issue was random disconnections.
My ISP suggested a few things, including contacting my phone company
and asking them to increase the line gain from the standard 1 to the
maximum of 3.
However, this is fine with a clean line but with a noisy line will
only increase the noise and also increase the likelihood of random
disconnections, so first get the noise problem sorted out.
When my phone company examined my nearest public routing/junction
cabinet the engineer discovered that during heavy rainfall the water
had been seeping into the cabinet and had gradually eroded some of the
contacts; these were replaced and the line gain was increased to its
maximum and now I connect at 50667bps for 90% of the time (49333bps
the rest of the time). The connection rate is also now much more
stable with only an occasional random disconnection.
I live in the UK by the way.
Don't know if any of this info helps?
PS. I'm using Windows98 with an internal "Conexant HCF V90 56K Data
Fax RTAD PCI Modem". I've also used a "Rockwell 56K ACF II
Fax+Data+Voice Modem" (external) with so-so results.
H
half_pint
Gary D. said:
It might also be worth him checking inside the telephone sockets inside
his home as water and condensation can get inside and corode the contacts,
or make false connections across them.
I had this happen to me, the engineer chased a noisy line down to corosion
inside one of the sockets.
F
Franc Zabkar
Yes, bandpass filters.
If you mean your statements regarding port speeds (57600bps), then see
my other post in this thread.
- Franc Zabkar
F
Franc Zabkar
Look again at my test results. In the first test the modem transmits a
file consisting of 1 million bytes in 298 seconds. This corresponds to
a transfer rate of 3355.7 bytes per second. Since the modem-to-modem
speed is 33600bps, this means that each byte consists of 10 bits. In
the very next test the same data are transferred in only 249 seconds
simply because these unnecessary framing bits are discarded. So
stripping out these bits *does* affect the throughput.
BTW, in the majority of cases the modem is not "waiting" for anything.
Its DCE interface is working at full speed. The only exception is
where the data are highly compressible, or where the port rate is set
too low. See the third test where the modem is being bottlenecked by
its DTE rate of 115200bps.
Yep. You only need to look at the test results.
There is a timeout period after each character. IIRC, the duration is
3 character times. If an additional character does not arrive within
this timeout period, a partial data packet is sent.
That's because you have not installed your modem with the correct INF
file. Usually this happens when you allow Windows to use its built-in
generic, chipset-based, INF files. Had you installed your modem
properly, ie with the manufacturer's INF file, these check boxes would
be available to you. Furthermore, your modemlog will have appropriate
entries such as the following:
Send: ATDT*############<cr>
Recv: CARRIER 46667
Recv: PROTOCOL: LAP-M
Recv: COMPRESSION: V.42BIS
Recv: CONNECT 46667
Connection established at 46667bps.
Error-control on.
Data compression on.
Your registry should have these keys (or similar):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n\Settings
Compression_Off "%C"
Compression_On "%C3"
ErrorControl_Forced "\N2"
ErrorControl_Off "\N"
ErrorControl_On "\N3"
Having said all the above, in the absence of contrary settings, your
modem will revert to its power-on defaults which will include EC and
data compression, probably V.42 LAPM and V.42bis (or V.44 in the case
of V.92).
You need to learn about "autobauding". See below.
No. The modem has two interfaces, a DTE interface and a DCE interface.
The DTE speed is determined by your COM port settings. When you select
a data format of, say, 115200bps, 8N1, you are setting up the UART in
your COM port. When your software sends its first AT command (eg the
reset command, ATZ or AT&F) to your modem, the modem aligns itself to
the received data format by analysing the bit pattern, ie it
"autobauds".
The speed of connection between the two modems (ie the DCE speed) is
determined during the training phase. These are the sounds your modem
makes when it is probing and analysing the phone line soon after
dialing. Among other things, the modems determine the frequency
response of the line, and, based on what they find, they decide on
initial upload and download speeds which they believe will be
suitable. The DTE has absolutely no effect on this (unless you have
told the modem to limit its top speed to a certain value). My own
modem usually connects at 48000/26400bps (Rx/Tx), but will almost
immediately speedshift to 46667/28800bps once it starts to monitor the
line quality.
The only time DTE speed has any impact on modem performance is when it
is set so low that it becomes a bottleneck for data compression.
On the contrary, your testing methodology produces results which
cannot be reproduced by anyone, not even yourself. We have no idea as
to the data type, the speed of your connection, the Tx/Rx error rates,
whether there is any network congestion, whether you are using S/W or
H/W compression (MNP, V42bis, V44), which protocols you are using (eg
V.90 or V.92), etc, etc.
In fact, as a direct result of my controlled testing, it is obvious
that I can achieve slightly better throughput (~2%) by forcing my
modem to negotiate an MNP/V.42bis connection as opposed to the default
of V.42/V.42bis. This is because V.42 EC limits my modem to 128 byte
blocks whereas MNP gives me the option of 256 bytes. Using Sysmon to
monitor the download rate for a ZIP file at a sustained speed of
46667bps (confirmed by post-call diagnostics), I have improved the
throughput from 5.3KB/s to 5.4KB/s. I did this by adding "\N5 %C2 \A3"
to DUN's Extra Settings.
At 6.2KB/s that would equate to a DCE rate of around 52000bps. I doubt
that you are achieving this kind of connection. To find out either
way, dump the modem's post-call diagnostic report. See my other post
in this thread for instructions on how to do this.
.... which is 360,000 bps.
That's probably because you have either a "soft" or controllerless
internal modem. These modems don't have real COM ports, only emulated
ones. As such they are not limited by their port rates. OTOH, a "real"
modem (eg an external serial one) will be limited by the maximum DTE
rate, usually 115200bps. At 10 bits/byte this amounts to a max
throughput of only 11.5KB/s. My real internal Rockwell modem was
limited to 11.5KB/s until I configured it for 230400bps using
Rockwell's rockser.vxd driver.
Have a look at your modem properties. I believe you will find that
your port rate is set to 115200bps. I suspect that changing this to
something low like 2400bps will not affect the way your modem
performs.
Of course I'm assuming that you have not enabled software compression
in the "Server Types" window. If you have, then your software
precompresses all data before transferring it to the COM port, which
means the modem has nothing extra to do. Incidentally, not all ISPs
support software compression. Mine doesn't.
Actually, from a user's perspective, *throughput* is the most
important thing.
- Franc Zabkar
H
half_pint
This thread/posts have became a bit long so I though I would start
afresh
Anyway as an aside from our haggling over who is wrong and who is
right, it may well be both, as it turns out, depending on how the modem
is set-up! I have found out some intersting info.
A few points:-
It seems my modem is set up without error correction or compression
(from my modem log)
07-07-2004 18:15:28.97 - Error-control off or unknown.
07-07-2004 18:15:28.97 - Data compression off or unknown
That modem utility doesn't seem to work too well for my modem
at the moment (more on that later), as I am fairly sure I am getting
better than 300BPS!!!!!
===========================
HIGHEST RX rate............. 300 BPS
PROTOCOL.................... N/A
COMPRESSION................. N/A
Line QUALITY................ 255
Rx LEVEL.................... 214
Highest Rx State............ 00
Highest TX State............ 00
EQM Sum..................... FFFF
RBS Pattern................. FF
Rate Drop................... FF
Digital Loss................ FFFF
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
V90
OK
==========================
This may well be because the modem was not set up with the
manufacturers .inf file, as you pointed out.
I did some googling on my modem, although I didn't have much
to go on as I think I have binned the box and I don't recall ever
having a manual for it (cannot find it anyway!). All I could find
on the modem itself was 560 DTV (data voice fax), fortunately
I did manage to track it down from just this info.
http://www.hhosting.co.uk/modtech/support/AMBsupp.htm
http://www.modulartech.com (from not sure if direct link will work)
So I have got all the relevant bumpf from there, including I think,
the correct .inf file.
Mine is the V90 so I should be able to upgrade it, see below.
===========================================
* Faster connection speeds to the same number (by
remembering the line characteristics from the previous
connection)
* Higher upload speeds (Max 44K instead of 33.6)
* Apparently higher speed for display of web-pages
(using V.44 compression which is optimised for HTML)
* Supports putting the modem 'on-hold' to take an
incoming call (see note 11 below)
These benefits are only supported if V.92 is fully
implemented by your ISP AND you have a V.92 modem
=============================================
Anyway I will not mess around with it for the moment as I am aware
I will destroy the modem if I screw-up up when updating its flash
memory. (Need to check with ISP too).
I have the proper .inf file now I think, Mdmcir.inf (there is also a
Serwvcir.inf file too). I am not sure how to 'install' this though,
I was thinking I could just replace the contents of the existing .inf
file (although I forget its name (I am sure you or I mentioned it in this
thread somewhere?)) mdmcomm1.inf mdmcom1.inf??
For the moment though I will 'leave well alone' I really don't want
risk losing my internet connection untill I am absolutely sure what
I am doing!! And I would want to research a new modem before
I attempt to 'flash' the modems memory so I can quickly nip down
to the a local computer shop if necessary.
I am not sure how worthwhile the v92 upgrade would be, a faster
connection would be nice but I doubt it would be much faster?
It takes about 22 seconds at the moment (I recently did something
to speed up the logging process). Also I managed to 'silence'
my modem a while back (I forget how and how to restore it)
so I cannot hear how long each bit takes.
"* Faster connection speeds to the same number (by
remembering the line characteristics from the previous
connection)"
I assume this is the bit where you hear the characteristic screeching
tones? as it tries higher and higher baud rates?
As for the other benefits:-
* Higher upload speeds (Max 44K instead of 33.6)
(don't really do much uploading)
* Apparently higher speed for display of web-pages
(using V.44 compression which is optimised for HTML)
(doubt I would notice the difference, it won't improve badly
designed sites, with their big pictures and fancy graphic etc...)
* Supports putting the modem 'on-hold' to take an
incoming call (see note 11 below)
11. Note that in order to benefit from V.92's incoming
call notification, you will need to subscribe to
your telecomms provider's call-waiting feature.
(I don't have this, unless it is free - I am in the UK with BT.)
Actually I can try using the correct .inf file with a fall back if I
screw it up, as I have a slave drive which is an oldish mirror of
my current drive so if the worst comes to the worst I can
simply swap drives and I will have an internet connection back.
I may do it if I am feeling brave, its a year out of date and I deleted
some 'unnecesary' stuff off it recently.
I may be being a bit over cautious I can't really imagine being without
an internet connection.
I will probably come back on some of the other points later as there
are too many 'unknows' about my connection at the moment.
I suspect I may be using some MPN 4 stuff but its hard to say for
sure untill I can 'interrogate' my modem properly!
Also it can get a little complicated if, for example, you have to
resend packets of data as to what the correct line speed is.
Line speed is perhaps more of a variable than a constant,
depending on the line quality. If you have a good line it will be
more of a constant of course. A bit of a 'black art' really!!
Anyway I will leave it at that for the moment.
Just one final point, the OP may be getting slow data rate because
his ISP is restricting it at their end, bandwidth costs, and I know
some broadband folks are restricted to 1 gig a month.
I also know I could get 3 gig out of my cheaper dial up
connection! (in 150 hours at about 20meg an hour), I use
more than 150 hours but at low data rates, if I started doing
a lot of downloads within the same hours I suspect my ISP
might start kicking up a fuss!!)
afresh
Anyway as an aside from our haggling over who is wrong and who is
right, it may well be both, as it turns out, depending on how the modem
is set-up! I have found out some intersting info.
A few points:-
It seems my modem is set up without error correction or compression
(from my modem log)
07-07-2004 18:15:28.97 - Error-control off or unknown.
07-07-2004 18:15:28.97 - Data compression off or unknown
That modem utility doesn't seem to work too well for my modem
at the moment (more on that later), as I am fairly sure I am getting
better than 300BPS!!!!!
===========================
HIGHEST RX rate............. 300 BPS
PROTOCOL.................... N/A
COMPRESSION................. N/A
Line QUALITY................ 255
Rx LEVEL.................... 214
Highest Rx State............ 00
Highest TX State............ 00
EQM Sum..................... FFFF
RBS Pattern................. FF
Rate Drop................... FF
Digital Loss................ FFFF
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
V90
OK
==========================
This may well be because the modem was not set up with the
manufacturers .inf file, as you pointed out.
I did some googling on my modem, although I didn't have much
to go on as I think I have binned the box and I don't recall ever
having a manual for it (cannot find it anyway!). All I could find
on the modem itself was 560 DTV (data voice fax), fortunately
I did manage to track it down from just this info.
http://www.hhosting.co.uk/modtech/support/AMBsupp.htm
http://www.modulartech.com (from not sure if direct link will work)
So I have got all the relevant bumpf from there, including I think,
the correct .inf file.
Mine is the V90 so I should be able to upgrade it, see below.
===========================================
* Faster connection speeds to the same number (by
remembering the line characteristics from the previous
connection)
* Higher upload speeds (Max 44K instead of 33.6)
* Apparently higher speed for display of web-pages
(using V.44 compression which is optimised for HTML)
* Supports putting the modem 'on-hold' to take an
incoming call (see note 11 below)
These benefits are only supported if V.92 is fully
implemented by your ISP AND you have a V.92 modem
=============================================
Anyway I will not mess around with it for the moment as I am aware
I will destroy the modem if I screw-up up when updating its flash
memory. (Need to check with ISP too).
I have the proper .inf file now I think, Mdmcir.inf (there is also a
Serwvcir.inf file too). I am not sure how to 'install' this though,
I was thinking I could just replace the contents of the existing .inf
file (although I forget its name (I am sure you or I mentioned it in this
thread somewhere?)) mdmcomm1.inf mdmcom1.inf??
For the moment though I will 'leave well alone' I really don't want
risk losing my internet connection untill I am absolutely sure what
I am doing!! And I would want to research a new modem before
I attempt to 'flash' the modems memory so I can quickly nip down
to the a local computer shop if necessary.
I am not sure how worthwhile the v92 upgrade would be, a faster
connection would be nice but I doubt it would be much faster?
It takes about 22 seconds at the moment (I recently did something
to speed up the logging process). Also I managed to 'silence'
my modem a while back (I forget how and how to restore it)
so I cannot hear how long each bit takes.
"* Faster connection speeds to the same number (by
remembering the line characteristics from the previous
connection)"
I assume this is the bit where you hear the characteristic screeching
tones? as it tries higher and higher baud rates?
As for the other benefits:-
* Higher upload speeds (Max 44K instead of 33.6)
(don't really do much uploading)
* Apparently higher speed for display of web-pages
(using V.44 compression which is optimised for HTML)
(doubt I would notice the difference, it won't improve badly
designed sites, with their big pictures and fancy graphic etc...)
* Supports putting the modem 'on-hold' to take an
incoming call (see note 11 below)
11. Note that in order to benefit from V.92's incoming
call notification, you will need to subscribe to
your telecomms provider's call-waiting feature.
(I don't have this, unless it is free - I am in the UK with BT.)
Actually I can try using the correct .inf file with a fall back if I
screw it up, as I have a slave drive which is an oldish mirror of
my current drive so if the worst comes to the worst I can
simply swap drives and I will have an internet connection back.
I may do it if I am feeling brave, its a year out of date and I deleted
some 'unnecesary' stuff off it recently.
I may be being a bit over cautious I can't really imagine being without
an internet connection.
I will probably come back on some of the other points later as there
are too many 'unknows' about my connection at the moment.
I suspect I may be using some MPN 4 stuff but its hard to say for
sure untill I can 'interrogate' my modem properly!
Also it can get a little complicated if, for example, you have to
resend packets of data as to what the correct line speed is.
Line speed is perhaps more of a variable than a constant,
depending on the line quality. If you have a good line it will be
more of a constant of course. A bit of a 'black art' really!!
Anyway I will leave it at that for the moment.
Just one final point, the OP may be getting slow data rate because
his ISP is restricting it at their end, bandwidth costs, and I know
some broadband folks are restricted to 1 gig a month.
I also know I could get 3 gig out of my cheaper dial up
connection! (in 150 hours at about 20meg an hour), I use
more than 150 hours but at low data rates, if I started doing
a lot of downloads within the same hours I suspect my ISP
might start kicking up a fuss!!)
G
Gary D.
H
half_pint
Gary D. said:
Z
Zotin Khuma
Gary D. said: