Modem connection speed

[Neil Barnwell]

On our standard 56k dialup modem (in the UK, this is), we only get ~38k when
we connect. Are there any ways to correct this? I've considered calling
the phone company and asking them to turn up the gain, but I've also been
told that this wouldn't make any difference.

Drivers etc are all up to date and this is happening on 2 computers in our
house, so does anyone have any ideas?

Cheers for your help.

<Barney />

[Art Leonard]

Line quality might be the limiting factor. See if you can get the line
provider and the isp provider to check it for you.

Art Leonard

Neil Barnwell wrote:
On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />

[Alex B]

56k = 56k max if you're lucky. I've never been about 44k when forced to use
dial up (usually when fixing virus infected laptops in work).


"Art Leonard" <Kufukahn@earthlink.net> wrote in message
news:Hw0Fc.1600$oD3.211@newsread1.news.pas.earthlink.net... Line quality might be the limiting factor. See if you can get the line provider and the isp provider to check it for you. Art Leonard Neil Barnwell wrote: On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />

[DaveW]

Your computer's distance from the local telephone switch determines what the
speed of your connection is. If you live next door to the switch office
you'll get the 55k. If you live 10 miles away, you may only get 24k. The
level of line noise that the telephone company allows on its lines also
affects the transmission speed.

--
DaveW



"Neil Barnwell" <neilbarnwell@hotmail.com> wrote in message
news:cc20ul$k2u$1@newsg3.svr.pol.co.uk... On our standard 56k dialup modem (in the UK, this is), we only get ~38k
when we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />

[yak]

In article <cc20ul$k2u$1@newsg3.svr.pol.co.uk>, neilbarnwell@hotmail.com
says... On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />


My max connect is 28.8 with a 56k modem.

It's all down to what speed the telco wants you to connect.

Cheap telco (sbc...) + muxxed line = twice the number of customers
without upgrading equipment.

bastards.

[half_pint]

"Neil Barnwell" <neilbarnwell@hotmail.com> wrote in message
news:cc20ul$k2u$1@newsg3.svr.pol.co.uk... On our standard 56k dialup modem (in the UK, this is), we only get ~38k
when we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help.
You need to pretty careful when talking about modem speeds,
if you use a stop bit then there are 9 bits to the byte, so to speak.

So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on tests
and mine uses one stop bit.


<Barney />

[half_pint]

"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message
news:cc25ac$65l$1@news7.svr.pol.co.uk... 56k = 56k max if you're lucky. I've never been about 44k when forced to
use dial up (usually when fixing virus infected laptops in work).

Well if you divide your 44 by 8 to get bits its 5.5 then times 10
to get bits including start and stop bits which is quite close the mythical
56k,
incidently the max rate I get on downloads is also 4.4 KBytes/second.

You will never transmit 56k of data bits in a second because extra bits
are added, the start and stop bits.

Sounds like you connection was working at a full 56k.

I could be wrong of course, but that doesnt happen very often.

--
half_pint



"Art Leonard" <Kufukahn@earthlink.net> wrote in message news:Hw0Fc.1600$oD3.211@newsread1.news.pas.earthlink.net... Line quality might be the limiting factor. See if you can get the line provider and the isp provider to check it for you. Art Leonard Neil Barnwell wrote: On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered
calling the phone company and asking them to turn up the gain, but I've also
been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />

[half_pint]

"DaveW" <none@zero.org> wrote in message
news:mN0Fc.9499$XM6.8238@attbi_s53... Your computer's distance from the local telephone switch determines what
the speed of your connection is. If you live next door to the switch office you'll get the 55k. If you live 10 miles away, you may only get 24k. The level of line noise that the telephone company allows on its lines also affects the transmission speed.


His line will probably take broadband. which is 10 times the bandwith -- DaveW "Neil Barnwell" <neilbarnwell@hotmail.com> wrote in message news:cc20ul$k2u$1@newsg3.svr.pol.co.uk... On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered
calling the phone company and asking them to turn up the gain, but I've also
been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in
our house, so does anyone have any ideas? Cheers for your help. <Barney />

[half_pint]

"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message
news:cc25ac$65l$1@news7.svr.pol.co.uk... 56k = 56k max if you're lucky. I've never been about 44k when forced to
use dial up (usually when fixing virus infected laptops in work).


You appear to be saying you have a broadband capable line
which is not capable of transmitting 56kbits/s, now that is
a rather slow broadband isnt it?


"Art Leonard" <Kufukahn@earthlink.net> wrote in message news:Hw0Fc.1600$oD3.211@newsread1.news.pas.earthlink.net... Line quality might be the limiting factor. See if you can get the line provider and the isp provider to check it for you. Art Leonard Neil Barnwell wrote: On our standard 56k dialup modem (in the UK, this is), we only get ~38k when we connect. Are there any ways to correct this? I've considered
calling the phone company and asking them to turn up the gain, but I've also
been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help. <Barney />

[half_pint]

Try this

http://www.analogx.com/contents/download/network/nsl.htm

Just testing it my self, but it seems good, very useful, it shows me
receiving
data at a max 25.4KB and average of 6.2KB i think thats kilo bytes (must
be).

I used some pics from a newsgroup to tesy it (far to rude to say which one)
but basically you need to connected to a site (or newsgroup) which has
good through put at its end.


"Art Leonard" <Kufukahn@earthlink.net> wrote in message
news:Hw0Fc.1600$oD3.211@newsread1.news.pas.earthlink.net... Line quality might be the limiting factor. See if you can get the line provider and the isp provider to check it for you. Art Leonard Neil Barnwell wrote: On our standard 56k dialup modem (in the UK, this is), we only get ~38k
when we connect. Are there any ways to correct this? I've considered
calling the phone company and asking them to turn up the gain, but I've also
been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in
our house, so does anyone have any ideas? Cheers for your help. <Barney />

[Franc Zabkar]

On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint"
<esboella.spamno@yahoo.com> put finger to keyboard and composed:
"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in messagenews:cc25ac$65l$1@news7.svr.pol.co.uk... 56k = 56k max if you're lucky. I've never been about 44k when forced touse dial up (usually when fixing virus infected laptops in work).Well if you divide your 44 by 8 to get bits its 5.5 then times 10to get bits including start and stop bits which is quite close the mythical56k,

By "44k" the OP means that he is connecting at 44000 bits per second.
It makes no sense to divide by 8 and multiply by 10.

If the OP has error correction disabled, then he will be downloading
at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit +
8 data bits + 1 stop bit).

If EC is enabled, then there are no start or stop bits. Instead the
data are packetised to give an average of 8.37 bits per byte
(according to my testing).

See my test results in this post:

"Test results - compression and error correction"
http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&output=gplain

Error Data Transfer MNP Throughput Bits
Correction Compression Time block (bytes/sec) per
(sec) size byte
---------------------------------------------------------------
None None 298 - 3356 10.0
V.42 LAPM None 249 - 4016 8.37
V.42 LAPM V.42bis 87 - 11494 2.92*
MNP 4 MNP 5 218 128 4587 7.32
MNP 4 None 263 64 3802 8.84
MNP 4 None 252 128 3968 8.47
MNP 4 None 244 256 4098 8.20
incidently the max rate I get on downloads is also 4.4 KBytes/second.You will never transmit 56k of data bits in a second because extra bitsare added, the start and stop bits.

Only at the DTE interface. They are stripped out by the DCE in EC
mode, as described above.
Sounds like you connection was working at a full 56k.

No. If that were the case, then how would you explain those cases
where people connect at 50667bps or better?
I could be wrong of course, but that doesnt happen very often.

Well, it's happened this time. :-)


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[Franc Zabkar]

On Fri, 2 Jul 2004 19:38:16 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Neil Barnwell" <neilbarnwell@hotmail.com> wrote in messagenews:cc20ul$k2u$1@newsg3.svr.pol.co.uk... On our standard 56k dialup modem (in the UK, this is), we only get ~38kwhen we connect. Are there any ways to correct this? I've considered calling the phone company and asking them to turn up the gain, but I've also been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in our house, so does anyone have any ideas? Cheers for your help.You need to pretty careful when talking about modem speeds,if you use a stop bit then there are 9 bits to the byte, so to speak.So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on testsand mine uses one stop bit.

Sorry, but none of this makes any sense. See my other post in this
thread.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com... On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint" <esboella.spamno@yahoo.com> put finger to keyboard and composed:"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in messagenews:cc25ac$65l$1@news7.svr.pol.co.uk... 56k = 56k max if you're lucky. I've never been about 44k when forced
touse dial up (usually when fixing virus infected laptops in work).Well if you divide your 44 by 8 to get bits its 5.5 then times 10to get bits including start and stop bits which is quite close the
mythical56k, By "44k" the OP means that he is connecting at 44000 bits per second. It makes no sense to divide by 8 and multiply by 10.

He means what he said (not too clear). If the OP has error correction disabled, then he will be downloading at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit + 8 data bits + 1 stop bit).


The OP said he was getting ~38 actually, however If EC is enabled,then there are no start or stop bits. Instead the data are packetised to give an average of 8.37 bits per byte (according to my testing). See my test results in this post: "Test results - compression and error correction"
http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&output=gplain Error Data Transfer MNP Throughput Bits Correction Compression Time block (bytes/sec) per (sec) size byte --------------------------------------------------------------- None None 298 - 3356 10.0 V.42 LAPM None 249 - 4016 8.37 V.42 LAPM V.42bis 87 - 11494 2.92* MNP 4 MNP 5 218 128 4587 7.32 MNP 4 None 263 64 3802 8.84 MNP 4 None 252 128 3968 8.47 MNP 4 None 244 256 4098 8.20incidently the max rate I get on downloads is also 4.4 KBytes/second.You will never transmit 56k of data bits in a second because extra bitsare added, the start and stop bits. Only at the DTE interface. They are stripped out by the DCE in EC mode, as described above.Sounds like you connection was working at a full 56k. No. If that were the case, then how would you explain those cases where people connect at 50667bps or better?I could be wrong of course, but that doesnt happen very often. Well, it's happened this time. :-)


I think you need to re-read my posts where a filesize in bytes is
simply multiplied by 8 to get bits them divided my time to get
a bits per second rate, clearly this will not take into accound start
and stop bits.

I don't think so, as I am pretty sure 99% of people connect at full speed
and any apparent delays in speed are due to there reasons other than the
telpphone line quality
- Franc Zabkar -- Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:9pgce09ipas01fhepqdoc0aakqebgl82tc@4ax.com... On Fri, 2 Jul 2004 19:38:16 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Neil Barnwell" <neilbarnwell@hotmail.com> wrote in messagenews:cc20ul$k2u$1@newsg3.svr.pol.co.uk... On our standard 56k dialup modem (in the UK, this is), we only get ~38kwhen we connect. Are there any ways to correct this? I've considered
calling the phone company and asking them to turn up the gain, but I've also
been told that this wouldn't make any difference. Drivers etc are all up to date and this is happening on 2 computers in
our house, so does anyone have any ideas? Cheers for your help.You need to pretty careful when talking about modem speeds,if you use a stop bit then there are 9 bits to the byte, so to speak.So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on testsand mine uses one stop bit. Sorry, but none of this makes any sense. See my other post in this thread.

I've seen them, I forgot about the start bit here but i corrected that in a
slightly later
post. See my response. - Franc Zabkar -- Please remove one 's' from my address when replying by email.

[half_pint]

Also the OP may make things clearer if he downloads the
software I recommened as it is easy to get misleading results using
some other methods.

Incidently the software shows my speed to be about
6.2 KB/s which is far faster then is ever reported by
other methods

The OP does not say how he obtained his figures and
I am fairly sure the method he used was incorrect/
misleading.

If he used something like Kazza or other fileshareing software
for instance, it will probably be wrong.

[Steve]

Franc Zabkar wrote:
You need to pretty careful when talking about modem speeds,if you use a stop bit then there are 9 bits to the byte, so to speak.So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on testsand mine uses one stop bit. Sorry, but none of this makes any sense. See my other post in this thread.

Not unusual for half_wit...er...half_pint.

[half_pint]

"ric" <nospam@home.com> wrote in message news:40E709F5.7169FA4F@home.com... Franc Zabkar wrote:You need to pretty careful when talking about modem speeds,if you use a stop bit then there are 9 bits to the byte, so to speak.So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on testsand mine uses one stop bit. Sorry, but none of this makes any sense. See my other post in this thread. Not unusual for half_wit...er...half_pint.

My posts are correct, many modem speed calculation methods
are incorrect as I have demonstrated.

Typically you have nothing to contribute to the subject.

[half_pint]

"ric" <nospam@home.com> wrote in message news:40E709F5.7169FA4F@home.com... Franc Zabkar wrote:You need to pretty careful when talking about modem speeds,if you use a stop bit then there are 9 bits to the byte, so to speak.So...56/9 ~= 6 (6X9=54) so 6X8=48 which is the max I get on testsand mine uses one stop bit. Sorry, but none of this makes any sense. See my other post in this thread. Not unusual for half_wit...er...half_pint.

I bet you have them rolling in the isles with wit like that :O|

[Franc Zabkar]

On Sat, 3 Jul 2004 19:25:53 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com... On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint" <esboella.spamno@yahoo.com> put finger to keyboard and composed:"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in messagenews:cc25ac$65l$1@news7.svr.pol.co.uk...> 56k = 56k max if you're lucky. I've never been about 44k when forcedtouse> dial up (usually when fixing virus infected laptops in work).Well if you divide your 44 by 8 to get bits its 5.5 then times 10to get bits including start and stop bits which is quite close themythical56k, By "44k" the OP means that he is connecting at 44000 bits per second. It makes no sense to divide by 8 and multiply by 10.He means what he said (not too clear). If the OP has error correction disabled, then he will be downloading at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit + 8 data bits + 1 stop bit).The OP said he was getting ~38 actually, however If EC is enabled,then there are no start or stop bits. Instead the data are packetised to give an average of 8.37 bits per byte (according to my testing). See my test results in this post: "Test results - compression and error correction"http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&output=gplain Error Data Transfer MNP Throughput Bits Correction Compression Time block (bytes/sec) per (sec) size byte --------------------------------------------------------------- None None 298 - 3356 10.0 V.42 LAPM None 249 - 4016 8.37 V.42 LAPM V.42bis 87 - 11494 2.92* MNP 4 MNP 5 218 128 4587 7.32 MNP 4 None 263 64 3802 8.84 MNP 4 None 252 128 3968 8.47 MNP 4 None 244 256 4098 8.20incidently the max rate I get on downloads is also 4.4 KBytes/second.You will never transmit 56k of data bits in a second because extra bitsare added, the start and stop bits. Only at the DTE interface. They are stripped out by the DCE in EC mode, as described above.Sounds like you connection was working at a full 56k. No. If that were the case, then how would you explain those cases where people connect at 50667bps or better?I could be wrong of course, but that doesnt happen very often. Well, it's happened this time. :-)I think you need to re-read my posts where a filesize in bytes issimply multiplied by 8 to get bits them divided my time to geta bits per second rate, clearly this will not take into accound startand stop bits.I don't think so, as I am pretty sure 99% of people connect at full speedand any apparent delays in speed are due to there reasons other than thetelpphone line quality

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
--
Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:99nge0h1fm560i53tqi2q72cb0i83gj3ad@4ax.com... On Sat, 3 Jul 2004 19:25:53 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com... On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint" <esboella.spamno@yahoo.com> put finger to keyboard and composed: > >"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message >news:cc25ac$65l$1@news7.svr.pol.co.uk... >> 56k = 56k max if you're lucky. I've never been about 44k when
forcedto >use >> dial up (usually when fixing virus infected laptops in work). > >Well if you divide your 44 by 8 to get bits its 5.5 then times 10 >to get bits including start and stop bits which is quite close themythical >56k, By "44k" the OP means that he is connecting at 44000 bits per second. It makes no sense to divide by 8 and multiply by 10.He means what he said (not too clear). If the OP has error correction disabled, then he will be downloading at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit + 8 data bits + 1 stop bit).The OP said he was getting ~38 actually, however If EC is enabled,then there are no start or stop bits. Instead the data are packetised to give an average of 8.37 bits per byte (according to my testing). See my test results in this post: "Test results - compression and error correction"http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.
au&output=gplain Error Data Transfer MNP Throughput Bits Correction Compression Time block (bytes/sec) per (sec) size byte --------------------------------------------------------------- None None 298 - 3356 10.0 V.42 LAPM None 249 - 4016 8.37 V.42 LAPM V.42bis 87 - 11494 2.92* MNP 4 MNP 5 218 128 4587 7.32 MNP 4 None 263 64 3802 8.84 MNP 4 None 252 128 3968 8.47 MNP 4 None 244 256 4098 8.20 >incidently the max rate I get on downloads is also 4.4 KBytes/second. > >You will never transmit 56k of data bits in a second because extra
bits >are added, the start and stop bits. Only at the DTE interface. They are stripped out by the DCE in EC mode, as described above. >Sounds like you connection was working at a full 56k. No. If that were the case, then how would you explain those cases where people connect at 50667bps or better? >I could be wrong of course, but that doesnt happen very often. Well, it's happened this time. :-)I think you need to re-read my posts where a filesize in bytes issimply multiplied by 8 to get bits them divided my time to geta bits per second rate, clearly this will not take into accound startand stop bits.I don't think so, as I am pretty sure 99% of people connect at full speedand any apparent delays in speed are due to there reasons other than thetelpphone line quality 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.

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.
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.

The utility I mentioned in this thread shows me receiving data at 6.2KBs
- Franc Zabkar -- Please remove one 's' from my address when replying by email.

[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?

[half_pint]

"half_pint" <esboella.arse@yahoo.com> wrote in message
news:2krrrgF5of2uU1@uni-berlin.de... Actually I now accept that the modems (to modem) may not be using stop and start bits.

.......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!!

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?

[Franc Zabkar]

On Sun, 4 Jul 2004 23:24:53 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:99nge0h1fm560i53tqi2q72cb0i83gj3ad@4ax.com... On Sat, 3 Jul 2004 19:25:53 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com...> On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint"> <esboella.spamno@yahoo.com> put finger to keyboard and composed:>> >> >"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message> >news:cc25ac$65l$1@news7.svr.pol.co.uk...> >> 56k = 56k max if you're lucky. I've never been about 44k whenforcedto> >use> >> dial up (usually when fixing virus infected laptops in work).> >> >Well if you divide your 44 by 8 to get bits its 5.5 then times 10> >to get bits including start and stop bits which is quite close themythical> >56k,>> By "44k" the OP means that he is connecting at 44000 bits per second.> It makes no sense to divide by 8 and multiply by 10.He means what he said (not too clear).>> If the OP has error correction disabled, then he will be downloading> at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit +> 8 data bits + 1 stop bit).The OP said he was getting ~38 actually, however>> If EC is enabled,>then there are no start or stop bits. Instead the> data are packetised to give an average of 8.37 bits per byte> (according to my testing).>> See my test results in this post:>> "Test results - compression and error correction">http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&output=gplain>> Error Data Transfer MNP Throughput Bits> Correction Compression Time block (bytes/sec) per> (sec) size byte> ---------------------------------------------------------------> None None 298 - 3356 10.0> V.42 LAPM None 249 - 4016 8.37> V.42 LAPM V.42bis 87 - 11494 2.92*> MNP 4 MNP 5 218 128 4587 7.32> MNP 4 None 263 64 3802 8.84> MNP 4 None 252 128 3968 8.47> MNP 4 None 244 256 4098 8.20>> >incidently the max rate I get on downloads is also 4.4 KBytes/second.> >> >You will never transmit 56k of data bits in a second because extrabits> >are added, the start and stop bits.>> Only at the DTE interface. They are stripped out by the DCE in EC> mode, as described above.>> >Sounds like you connection was working at a full 56k.>> No. If that were the case, then how would you explain those cases> where people connect at 50667bps or better?>> >I could be wrong of course, but that doesnt happen very often.>> Well, it's happened this time. :-)I think you need to re-read my posts where a filesize in bytes issimply multiplied by 8 to get bits them divided my time to geta bits per second rate, clearly this will not take into accound startand stop bits.I don't think so, as I am pretty sure 99% of people connect at full speedand any apparent delays in speed are due to there reasons other than thetelpphone line quality 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.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.

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.
You will have to explain yourself better as I am not surewhat error correction you are on about.

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.
As far as I can see there is no option to 'disable errorconnection' in internet options,

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".
you can forget Hyperterminalbecause I don't use it (as far as I am aware) and neither does the OP.

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.
So i am not really to sure what you are getting at because when Ilook at my modem properties is says 8 data, 1 stop bit and noparity bit (I presume the start bit is taken for granted).Because it says this I have to believe what I see and take itas fact as that is what the modem is doing.

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.
If it was configured otherwise I am sure it would say so.

DUN has no idea what transpires between the two modems. Such things
are mostly beyond its control.
If you can show me a link which clearly shows that these valueare not used I would like to see it.

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.
As I said your Hyper Terminal experiments are not really relevantas far as I can see.

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.
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.The utility I mentioned in this thread shows me receiving data at 6.2KBs

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
--
Please remove one 's' from my address when replying by email.

[Franc Zabkar]

On Mon, 5 Jul 2004 03:35:30 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
Incidently the utility I am using shows me receiveing data at 7.3 KBswhich is faster than a 56k modem is alledgedly capable!!

Think "data compression".
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?

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
--
Please remove one 's' from my address when replying by email.

[Franc Zabkar]

On Mon, 5 Jul 2004 03:16:39 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
Actually I now accept that the modems (to modem) may not be usingstop and start bits. However having said that I doubt his problem isdown to the telephone line which is probably capable of transmitting8 mega bits per second, I mean it would be a bit odd if it was onlymanaging 0.7% of its capacity, and even odder is several peoplemiraculously also received a similar degradation?

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
--
Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:0prhe0hig00t613dignl002v3dnsact12u@4ax.com... On Sun, 4 Jul 2004 23:24:53 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:99nge0h1fm560i53tqi2q72cb0i83gj3ad@4ax.com... On Sat, 3 Jul 2004 19:25:53 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed: > >"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message >news:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com... >> On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint" >> <esboella.spamno@yahoo.com> put finger to keyboard and composed: >> >> > >> >"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message >> >news:cc25ac$65l$1@news7.svr.pol.co.uk... >> >> 56k = 56k max if you're lucky. I've never been about 44k whenforced >to >> >use >> >> dial up (usually when fixing virus infected laptops in work). >> > >> >Well if you divide your 44 by 8 to get bits its 5.5 then times 10 >> >to get bits including start and stop bits which is quite close the >mythical >> >56k, >> >> By "44k" the OP means that he is connecting at 44000 bits per
second. >> It makes no sense to divide by 8 and multiply by 10. > >He means what he said (not too clear). >> >> If the OP has error correction disabled, then he will be downloading >> at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit
+ >> 8 data bits + 1 stop bit). > > >The OP said he was getting ~38 actually, however >> >> If EC is enabled, >>then there are no start or stop bits. Instead the >> data are packetised to give an average of 8.37 bits per byte >> (according to my testing). >> >> See my test results in this post: >> >> "Test results - compression and error correction" >>http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net
..au&output=gplain >> >> Error Data Transfer MNP Throughput Bits >> Correction Compression Time block (bytes/sec) per >> (sec) size byte >> --------------------------------------------------------------- >> None None 298 - 3356 10.0 >> V.42 LAPM None 249 - 4016 8.37 >> V.42 LAPM V.42bis 87 - 11494 2.92* >> MNP 4 MNP 5 218 128 4587 7.32 >> MNP 4 None 263 64 3802 8.84 >> MNP 4 None 252 128 3968 8.47 >> MNP 4 None 244 256 4098 8.20 >> >> >incidently the max rate I get on downloads is also 4.4
KBytes/second. >> > >> >You will never transmit 56k of data bits in a second because extrabits >> >are added, the start and stop bits. >> >> Only at the DTE interface. They are stripped out by the DCE in EC >> mode, as described above. >> >> >Sounds like you connection was working at a full 56k. >> >> No. If that were the case, then how would you explain those cases >> where people connect at 50667bps or better? >> >> >I could be wrong of course, but that doesnt happen very often. >> >> Well, it's happened this time. :-) > > >I think you need to re-read my posts where a filesize in bytes is >simply multiplied by 8 to get bits them divided my time to get >a bits per second rate, clearly this will not take into accound start >and stop bits. > >I don't think so, as I am pretty sure 99% of people connect at full
speed >and any apparent delays in speed are due to there reasons other than
the >telpphone line quality 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.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. 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.

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 will have to explain yourself better as I am not surewhat error correction you are on about. 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.


You sure about that? what about a 1 byte keystroke?

#As far as I can see there is no option to 'disable errorconnection' in internet options, 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".

Those obtions are not available on my PC, the boxes are there but
they are inaccessible.
you can forget Hyperterminalbecause I don't use it (as far as I am aware) and neither does the OP. 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.So i am not really to sure what you are getting at because when Ilook at my modem properties is says 8 data, 1 stop bit and noparity bit (I presume the start bit is taken for granted).Because it says this I have to believe what I see and take itas fact as that is what the modem is doing. 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.


I know the differemce and it says modem properties not DTE so you need
to learn to read what is written.

If it was configured otherwise I am sure it would say so. DUN has no idea what transpires between the two modems. Such things are mostly beyond its control.If you can show me a link which clearly shows that these valueare not used I would like to see it. 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.


It don't think it really matters as the comms speed it determinded by the
DTE
speed not the modem.
As I said your Hyper Terminal experiments are not really relevantas far as I can see. 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.


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.

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.The utility I mentioned in this thread shows me receiving data at 6.2KBs 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.


The data I am using is compressed data eg jpegs. FWIW, my internal modem can achieve download rates as high as 21KB/s when tranferring highly compressible data such as some newsgroup headers.

well mine is showing 36KBs but I would rather see what
rate bits are being transmitted at as anything else is pretty meaning less. - Franc Zabkar -- Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:nhshe018jqsvpb1n4h4bi34dcoqe8p3m81@4ax.com... On Mon, 5 Jul 2004 03:35:30 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:Incidently the utility I am using shows me receiveing data at 7.3 KBswhich is faster than a 56k modem is alledgedly capable!! Think "data compression".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? 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?
- Franc Zabkar -- Please remove one 's' from my address when replying by email.

[Franc Zabkar]

On Mon, 5 Jul 2004 18:59:18 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:nhshe018jqsvpb1n4h4bi34dcoqe8p3m81@4ax.com... On Mon, 5 Jul 2004 03:35:30 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:Incidently the utility I am using shows me receiveing data at 7.3 KBswhich is faster than a 56k modem is alledgedly capable!! Think "data compression".>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? 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.

Yes, bandpass filters.
You appear to have snipped out the bit which proves I was right all along?

If you mean your statements regarding port speeds (57600bps), then see
my other post in this thread.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[Franc Zabkar]

On Mon, 5 Jul 2004 18:56:02 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:0prhe0hig00t613dignl002v3dnsact12u@4ax.com... On Sun, 4 Jul 2004 23:24:53 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:99nge0h1fm560i53tqi2q72cb0i83gj3ad@4ax.com...> On Sat, 3 Jul 2004 19:25:53 +0100, "half_pint"> <esboella.arse@yahoo.com> put finger to keyboard and composed:>> >> >"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message> >news:5shce05edlrrmv5q6tt3fkl0nv00r24vsv@4ax.com...> >> On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint"> >> <esboella.spamno@yahoo.com> put finger to keyboard and composed:> >>> >> >> >> >"Alex B" <Freeflyer91@hotmail.com.NOSPAM> wrote in message> >> >news:cc25ac$65l$1@news7.svr.pol.co.uk...> >> >> 56k = 56k max if you're lucky. I've never been about 44k whenforced> >to> >> >use> >> >> dial up (usually when fixing virus infected laptops in work).> >> >> >> >Well if you divide your 44 by 8 to get bits its 5.5 then times 10> >> >to get bits including start and stop bits which is quite close the> >mythical> >> >56k,> >>> >> By "44k" the OP means that he is connecting at 44000 bits persecond.> >> It makes no sense to divide by 8 and multiply by 10.> >> >He means what he said (not too clear).> >>> >> If the OP has error correction disabled, then he will be downloading> >> at the rate of 4400 bytes per second (1 byte = 10 bits = 1 start bit+> >> 8 data bits + 1 stop bit).> >> >> >The OP said he was getting ~38 actually, however> >>> >> If EC is enabled,> >>then there are no start or stop bits. Instead the> >> data are packetised to give an average of 8.37 bits per byte> >> (according to my testing).> >>> >> See my test results in this post:> >>> >> "Test results - compression and error correction"> >>>http://groups.google.com/groups?selm=3b5ff0c7.6013011%40news.dingoblue.net.au&output=gplain> >>> >> Error Data Transfer MNP Throughput Bits> >> Correction Compression Time block (bytes/sec) per> >> (sec) size byte> >> ---------------------------------------------------------------> >> None None 298 - 3356 10.0> >> V.42 LAPM None 249 - 4016 8.37> >> V.42 LAPM V.42bis 87 - 11494 2.92*> >> MNP 4 MNP 5 218 128 4587 7.32> >> MNP 4 None 263 64 3802 8.84> >> MNP 4 None 252 128 3968 8.47> >> MNP 4 None 244 256 4098 8.20> >>> >> >incidently the max rate I get on downloads is also 4.4KBytes/second.> >> >> >> >You will never transmit 56k of data bits in a second because extrabits> >> >are added, the start and stop bits.> >>> >> Only at the DTE interface. They are stripped out by the DCE in EC> >> mode, as described above.> >>> >> >Sounds like you connection was working at a full 56k.> >>> >> No. If that were the case, then how would you explain those cases> >> where people connect at 50667bps or better?> >>> >> >I could be wrong of course, but that doesnt happen very often.> >>> >> Well, it's happened this time. :-)> >> >> >I think you need to re-read my posts where a filesize in bytes is> >simply multiplied by 8 to get bits them divided my time to get> >a bits per second rate, clearly this will not take into accound start> >and stop bits.> >> >I don't think so, as I am pretty sure 99% of people connect at fullspeed> >and any apparent delays in speed are due to there reasons other thanthe> >telpphone line quality>> 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.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. 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.I introduded the stop and start bit because they are relevantto the comms.Obviously even if these bits are stripped out by the modem ithas no effect on the overall speed because the modem stillhas to wait to receive these bits so it might as well transmit thembecause it will have bugger all else to do whilst it is waiting.

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.
You will have to explain yourself better as I am not surewhat error correction you are on about. 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.You sure about that?

Yep. You only need to look at the test results.
what about a 1 byte keystroke?

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.
As far as I can see there is no option to 'disable errorconnection' in internet options, 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".Those obtions are not available on my PC, the boxes are there butthey are inaccessible.

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 can forget Hyperterminalbecause I don't use it (as far as I am aware) and neither does the OP. 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.So i am not really to sure what you are getting at because when Ilook at my modem properties is says 8 data, 1 stop bit and noparity bit (I presume the start bit is taken for granted).Because it says this I have to believe what I see and take itas fact as that is what the modem is doing. 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.I know the differemce and it says modem properties not DTE so you needto learn to read what is written.

You need to learn about "autobauding". See below.
If it was configured otherwise I am sure it would say so. DUN has no idea what transpires between the two modems. Such things are mostly beyond its control.If you can show me a link which clearly shows that these valueare not used I would like to see it. 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.It don't think it really matters as the comms speed it determinded by theDTEspeed not the modem.

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.
As I said your Hyper Terminal experiments are not really relevantas far as I can see. 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.However you are not testing the right patient so to speak,you are testing a different patient and assuming the real patienthas the same symptoms you found on the proxy patient.A rather foolish way to diagnose a problem.

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.
> 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.The utility I mentioned in this thread shows me receiving data at 6.2KBs 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.The data I am using is compressed data eg jpegs.

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.
FWIW, my internal modem can achieve download rates as high as 21KB/s when tranferring highly compressible data such as some newsgroup headers.well mine is showing 36KBs ...

.... 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.
... but I would rather see whatrate bits are being transmitted at as anything else is pretty meaning less.

Actually, from a user's perspective, *throughput* is the most
important thing.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[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!!)

[Franc Zabkar]

On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
This thread/posts have became a bit long so I though I would startafresh

Excellent idea.
Anyway as an aside from our haggling over who is wrong and who isright, it may well be both, as it turns out, depending on how the modemis set-up! I have found out some intersting info.

Sorry, but you haven't been right about much, if anything, so far.

See this [old] URL:
http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html

"When V.42 error control is not used, start and stop bits are sent
with each character. Thus, an eight-bit character would take 10 bits
to transmit. Top-speed V.34 modems use V.42 error control. When V.42
error control is used, no start or stop bits are sent over the line.
The asynchronous bytes are stored until a standard packet size is
reached or a timeout elapses. Then they're wrapped in V.42 - or Link
Access Protocol for Modems - headers and sent synchronously."

"Latency - When keystroking, the modem may wait to see if more
characters are forthcoming before sending or may just have slow
store-and-forward code."

"Overhead - Each block, which may potentially be as small as a single
character of payload, may be surrounded by leading flag, address byte,
command byte, two CRC bytes and trailing flag for big expansion. ...
If the V.42 block size is 256 bytes, you still have six overhead bytes
for each 256 bytes."
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

Highly unlikely. You snipped out the important data just prior to
these two lines. If the modem was installed properly, you would have
seen responses such as "PROTOCOL: LAP-M" or "COMPRESSION: V.42BIS".
The fact that DUN reports no EC or data compression does not
necessarily mean that these protocols are disabled, instead it means
that the INF file, and therefore the registry, did not contain the
aforementioned responses. If these responses do not appear under this
registry key ...

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n\Responses

.... then DUN does not know how to interpret them and flags them as
"unknown".

Here's some useful info:

Understanding Your Modem Log
http://www.modemsite.com/56k/modemlog.asp
That modem utility doesn't seem to work too well for my modemat the moment (more on that later), as I am fairly sure I am gettingbetter than 300BPS!!!!!

This looks like the AT&V1 output from a Conexant/Rockwell chipset. The
data are meaningless because DUN has reset them. You need to edit the
Reset parameter at this registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n

Change the Reset command from "ATZ<cr>" to just a plain "AT<cr>".

In addition to AT&V1 there are more useful diagnostic commands such as
AT#UG or AT#UD. The output from the latter needs to be decoded.
===========================HIGHEST RX rate............. 300 BPSPROTOCOL.................... N/ACOMPRESSION................. N/ALine QUALITY................ 255Rx LEVEL.................... 214Highest Rx State............ 00Highest TX State............ 00EQM Sum..................... FFFFRBS Pattern................. FFRate Drop................... FFDigital Loss................ FFFFLocal Rtrn Count............ 00Remote Rtrn Count........... 00V90OK==========================This may well be because the modem was not set up with themanufacturers .inf file, as you pointed out.

No, it's a problem with nearly every INF file.

See "Prevent Modem Reset":
http://www.modemsite.com/56k/x2-inf.asp
I did some googling on my modem, although I didn't have muchto go on as I think I have binned the box and I don't recall everhaving a manual for it (cannot find it anyway!). All I could findon the modem itself was 560 DTV (data voice fax), fortunatelyI did manage to track it down from just this info.
http://www.hhosting.co.uk/modtech/support/AMBsupp.htm

Nope, wrong chipset, wrong modem type. This is an *external* modem
using an Ambient/Intel/Cirrus Logic chipset. You stated elsewhere that
yours was an *internal*.

Identifying Your Chipset
http://www.modemsite.com/56k/chipset.asp

Who Manufactured My Modem?
http://www.modemsite.com/56k/whomadeit.asp
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.

If it's a Conexant chipset, then here are generic Conexant drivers:
http://www.conexant.com/support/md_driverassistance.html
Anyway I will not mess around with it for the moment as I am awareI will destroy the modem if I screw-up up when updating its flashmemory. (Need to check with ISP too).

I suspect yours is an internal HSF (soft) or HCF (controllerless)
modem. If so, then it will have no flash memory. To prove this beyond
doubt, look for a chip with a part number containing 29xxxxx. No chip
means no flash.
I have the proper .inf file now I think, Mdmcir.inf

I doubt it. This is probably an INF for a Cirrus Logic chipset. Cirrus
Logic became Ambient, and then Ambient was absorbed by Intel.
(there is also aSerwvcir.inf file too). I am not sure how to 'install' this though,I was thinking I could just replace the contents of the existing .inffile (although I forget its name (I am sure you or I mentioned it in thisthread somewhere?)) mdmcomm1.inf mdmcom1.inf??

No. You must uninstall the current modem and then install the new one.
The installation process loads driver files (*.vxd) and rewrites the
registry.
For the moment though I will 'leave well alone' I really don't wantrisk losing my internet connection untill I am absolutely sure whatI am doing!! And I would want to research a new modem beforeI attempt to 'flash' the modems memory so I can quickly nip downto the a local computer shop if necessary.I am not sure how worthwhile the v92 upgrade would be, a fasterconnection would be nice but I doubt it would be much faster?It takes about 22 seconds at the moment (I recently did somethingto speed up the logging process).

I suspect you may have done this:

Slow to Logon
http://www.modemsite.com/56k/logon.asp

Here in Australia not many ISPs support V.92. In any case the benefits
are not substantial, especially if you can take advantage of software
compression.
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.

Does this help?

Can't Hear Modem - Modem Speaker On or Off
http://www.modemsite.com/56k/speaker.asp
"* 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 screechingtones? as it tries higher and higher baud rates?

It's not trying higher "baud rates". The modems are sending different
frequencies down the phone line and assessing the line's frequency
response, among other things. You can see the response curve in the
post-call diagnostic report of USR/3Com modems, for example.

See http://members.cruzio.com/~jeffl/aty11/aty11.htm and

http://groups.google.com/groups?selm=3583FA6A.2E642CB%40one.net&output=gplain
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 badlydesigned sites, with their big pictures and fancy graphic etc...)

V.42bis has a typical compression ration for text of 2:1. This is
almost enough to saturate a 11.5 KB/s COM port if the modems are
connected at 5KB/s. V.44 has a claimed compression ratio of 3:1
(IIRC), which would be throttled back to 2:1 by the COM port anyway.
So unless you have a high speed COM port (eg 230400bps), or a soft or
controllerless internal modem, or perhaps a USB modem, then AFAICS you
will see little, if any, performance increase.
I will probably come back on some of the other points later as thereare too many 'unknows' about my connection at the moment.I suspect I may be using some MPN 4 stuff but its hard to say forsure untill I can 'interrogate' my modem properly!

No, the default is V.42 LAPM and V.42bis.
Also it can get a little complicated if, for example, you have toresend 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 bemore of a constant of course. A bit of a 'black art' really!!

Your post-call diagnostics will tell you the error rates and the
numbers of speedshifts and retrains (see my other post). If the error
rate is high, then you may achieve higher throughput by limiting your
initial connect speed.

Limiting CONNECT speed:
http://www.modemsite.com/56k/x2-linklimit.asp

Here is my favourite site for all things modem:
http://www.modemsite.com/56k/trouble.asp

There may be some useful tests here:

Test Your Modem Speed
http://www.modemsite.com/56k/speedtest.asp

Personally I think the best on-line tests involve transferring ZIP
files to and from your own webspace using FTP, or emailing ZIPs to
yourself. This is because there is less chance for network congestion.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:cbbre092bssevqg6h1kvrtfiuhbu9dv6ve@4ax.com... On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:This thread/posts have became a bit long so I though I would startafresh Excellent idea.Anyway as an aside from our haggling over who is wrong and who isright, it may well be both, as it turns out, depending on how the modemis set-up! I have found out some intersting info. Sorry, but you haven't been right about much, if anything, so far.

In your opinion.
You don't now how my modem is configured, so basically you are clutching at
straws. You are talking about error correction and protocols when you don't
know how my modem or the OP's is configured.
See this [old] URL: http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html "When V.42 error control is not used, start and stop bits are sent with each character. Thus, an eight-bit character would take 10 bits to transmit. Top-speed V.34 modems use V.42 error control. When V.42 error control is used, no start or stop bits are sent over the line. The asynchronous bytes are stored until a standard packet size is reached or a timeout elapses. Then they're wrapped in V.42 - or Link Access Protocol for Modems - headers and sent synchronously." "Latency - When keystroking, the modem may wait to see if more characters are forthcoming before sending or may just have slow store-and-forward code." "Overhead - Each block, which may potentially be as small as a single character of payload, may be surrounded by leading flag, address byte, command byte, two CRC bytes and trailing flag for big expansion. ... If the V.42 block size is 256 bytes, you still have six overhead bytes for each 256 bytes."


Not relevant unless you know the modens config.
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 Highly unlikely. You snipped out the important data just prior to these two lines.

Wrong I snipped out nothing important, see the log at the end of file.
If the modem was installed properly, you would have seen responses such as "PROTOCOL: LAP-M" or "COMPRESSION: V.42BIS".

Only if it was set up a particular fashion.My modem works well
enough it has connected me to the internet for
several years. To suggest it is not installed properly is a bit of
a stretch.
The fact that DUN reports no EC or data compression does not necessarily mean that these protocols are disabled, instead it means that the INF file, and therefore the registry, did not contain the aforementioned responses. If these responses do not appear under this registry key ...
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n\Respon
ses ... then DUN does not know how to interpret them and flags them as "unknown".

Well there seems to a load of stuff in there.

Connect 28000 = 02 00 80 70 00 00 00 00 00 00
( for example)
OR
PROTOCOL LAPM = 00 02 00 00 00 00 00 00 00 00
Here's some useful info: Understanding Your Modem Log http://www.modemsite.com/56k/modemlog.aspThat modem utility doesn't seem to work too well for my modemat the moment (more on that later), as I am fairly sure I am gettingbetter than 300BPS!!!!! This looks like the AT&V1 output from a Conexant/Rockwell chipset. The data are meaningless because DUN has reset them. You need to edit the Reset parameter at this registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n Change the Reset command from "ATZ<cr>" to just a plain "AT<cr>". In addition to AT&V1 there are more useful diagnostic commands such as AT#UG or AT#UD. The output from the latter needs to be decoded.===========================HIGHEST RX rate............. 300 BPSPROTOCOL.................... N/ACOMPRESSION................. N/ALine QUALITY................ 255Rx LEVEL.................... 214Highest Rx State............ 00Highest TX State............ 00EQM Sum..................... FFFFRBS Pattern................. FFRate Drop................... FFDigital Loss................ FFFFLocal Rtrn Count............ 00Remote Rtrn Count........... 00V90OK==========================This may well be because the modem was not set up with themanufacturers .inf file, as you pointed out. No, it's a problem with nearly every INF file. See "Prevent Modem Reset": http://www.modemsite.com/56k/x2-inf.aspI did some googling on my modem, although I didn't have muchto go on as I think I have binned the box and I don't recall everhaving a manual for it (cannot find it anyway!). All I could findon the modem itself was 560 DTV (data voice fax), fortunatelyI did manage to track it down from just this info.http://www.hhosting.co.uk/modtech/support/AMBsupp.htm Nope, wrong chipset, wrong modem type. This is an *external* modem using an Ambient/Intel/Cirrus Logic chipset. You stated elsewhere that yours was an *internal*.

If I did do that (I don't recall) I did it in error, its the correct modem
alright.
I am fairly sure of that, (maybe a different case), they only do a few
modems.

Identifying Your Chipset http://www.modemsite.com/56k/chipset.asp Who Manufactured My Modem? http://www.modemsite.com/56k/whomadeit.asphttp://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. If it's a Conexant chipset, then here are generic Conexant drivers: http://www.conexant.com/support/md_driverassistance.htmlAnyway I will not mess around with it for the moment as I am awareI will destroy the modem if I screw-up up when updating its flashmemory. (Need to check with ISP too). I suspect yours is an internal HSF (soft) or HCF (controllerless) modem. If so, then it will have no flash memory. To prove this beyond doubt, look for a chip with a part number containing 29xxxxx. No chip means no flash.I have the proper .inf file now I think, Mdmcir.inf I doubt it. This is probably an INF for a Cirrus Logic chipset. Cirrus Logic became Ambient, and then Ambient was absorbed by Intel.

No its the right one. Mine is an old modem.
Definately the right one.
(there is also aSerwvcir.inf file too). I am not sure how to 'install' this though,I was thinking I could just replace the contents of the existing .inffile (although I forget its name (I am sure you or I mentioned it in thisthread somewhere?)) mdmcomm1.inf mdmcom1.inf?? No. You must uninstall the current modem and then install the new one. The installation process loads driver files (*.vxd) and rewrites the registry.

Can't I have several modems?
For the moment though I will 'leave well alone' I really don't wantrisk losing my internet connection untill I am absolutely sure whatI am doing!! And I would want to research a new modem beforeI attempt to 'flash' the modems memory so I can quickly nip downto the a local computer shop if necessary.I am not sure how worthwhile the v92 upgrade would be, a fasterconnection would be nice but I doubt it would be much faster?It takes about 22 seconds at the moment (I recently did somethingto speed up the logging process). I suspect you may have done this: Slow to Logon http://www.modemsite.com/56k/logon.asp Here in Australia not many ISPs support V.92. In any case the benefits are not substantial, especially if you can take advantage of software compression. 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. Does this help? Can't Hear Modem - Modem Speaker On or Off http://www.modemsite.com/56k/speaker.asp"* 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 screechingtones? as it tries higher and higher baud rates? It's not trying higher "baud rates". The modems are sending different frequencies down the phone line and assessing the line's frequency response, among other things.

Well basically the same thing, finding the best baud rate to use
"trying higher baud rates"
You can see the response curve in the post-call diagnostic report of USR/3Com modems, for example. See http://members.cruzio.com/~jeffl/aty11/aty11.htm and
http://groups.google.com/groups?selm=3583FA6A.2E642CB%40one.net&output=gplainAs 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 badlydesigned sites, with their big pictures and fancy graphic etc...) V.42bis has a typical compression ration for text of 2:1. This is almost enough to saturate a 11.5 KB/s COM port if the modems are connected at 5KB/s. V.44 has a claimed compression ratio of 3:1 (IIRC), which would be throttled back to 2:1 by the COM port anyway. So unless you have a high speed COM port (eg 230400bps), or a soft or controllerless internal modem, or perhaps a USB modem, then AFAICS you will see little, if any, performance increase.I will probably come back on some of the other points later as thereare too many 'unknows' about my connection at the moment.I suspect I may be using some MPN 4 stuff but its hard to say forsure untill I can 'interrogate' my modem properly! No, the default is V.42 LAPM and V.42bis.

Whatever. The default doen't matter too much, what matters is how the modem
is configured. Which is what I am trying to find out.Also it can get a little complicated if, for example, you have toresend 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 bemore of a constant of course. A bit of a 'black art' really!! Your post-call diagnostics will tell you the error rates and the numbers of speedshifts and retrains (see my other post).

Which one? the reason i am doing this is because I cannot
see such data in the first place!!
If the error rate is high, then you may achieve higher throughput by limiting your initial connect speed. Limiting CONNECT speed: http://www.modemsite.com/56k/x2-linklimit.asp Here is my favourite site for all things modem: http://www.modemsite.com/56k/trouble.asp There may be some useful tests here: Test Your Modem Speed http://www.modemsite.com/56k/speedtest.asp Personally I think the best on-line tests involve transferring ZIP files to and from your own webspace using FTP, or emailing ZIPs to yourself. This is because there is less chance for network congestion. - Franc Zabkar -- Please remove one 's' from my address when replying by email.


Modem log.

07-01-2004 21:45:26.89 - Recv: ATE0V1<cr>
07-01-2004 21:45:26.89 - Recv: <cr><lf>OK<cr><lf>
07-01-2004 21:45:26.89 - Interpreted response: Ok
07-01-2004 21:45:26.89 - Send: ATX4<cr>
07-01-2004 21:45:26.89 - Recv: <cr><lf>OK<cr><lf>
07-01-2004 21:45:26.89 - Interpreted response: Ok
07-01-2004 21:45:26.90 - Dialing.
07-01-2004 21:45:26.90 - Send: ATDT###########<cr>
07-01-2004 21:45:48.27 - Recv: <cr>
07-01-2004 21:45:48.27 - Interpreted response: Informative
07-01-2004 21:45:48.27 - Recv: <lf>
07-01-2004 21:45:48.27 - Interpreted response: Informative
07-01-2004 21:45:48.28 - Recv: CONNECT 57600
07-01-2004 21:45:48.28 - Interpreted response: Connect
07-01-2004 21:45:48.28 - Connection established at 57600bps.
07-01-2004 21:45:48.28 - Error-control off or unknown.
07-01-2004 21:45:48.28 - Data compression off or unknown.
07-01-2004 22:12:16.92 - Hanging up the modem.
07-01-2004 22:12:16.92 - Hardware hangup by lowering DTR.
07-01-2004 22:12:17.68 - Recv: <cr><lf>NO CARRIER<cr><lf>
07-01-2004 22:12:17.68 - Interpreted response: No Carrier
07-01-2004 22:12:17.68 - Send: ATH<cr>
07-01-2004 22:12:17.68 - Recv: <cr><lf>OK<cr><lf>
07-01-2004 22:12:17.68 - Interpreted response: Ok
07-01-2004 22:12:17.68 - 57600,N,8,1
07-01-2004 22:12:17.69 - Session Statistics:
07-01-2004 22:12:17.69 - Reads : 215484 bytes
07-01-2004 22:12:17.69 - Writes: 25019 bytes

[Franc Zabkar]

On Thu, 8 Jul 2004 23:01:24 +0100, "half_pint"
<esboella.arse@yahoo.com> put finger to keyboard and composed:
"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:cbbre092bssevqg6h1kvrtfiuhbu9dv6ve@4ax.com... On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:
Sorry, but you haven't been right about much, if anything, so far.
In your opinion.

Usenet is full of opinions and disinformation. That's why I support my
statements with authoritative references wherever possible. Even so,
I'm prepared to be proven wrong. Show me your data.
You don't now how my modem is configured, so basically you are clutching atstraws. You are talking about error correction and protocols when you don'tknow how my modem or the OP's is configured.

Until a few days ago you hadn't even heard of error correction and
data compression, yet now you are offering opinions on same.
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 Highly unlikely. You snipped out the important data just prior to these two lines.Wrong I snipped out nothing important, see the log at the end of file.

The log shows that you do not understand how to properly configure a
modem.
I did some googling on my modem, although I didn't have muchto go on as I think I have binned the box and I don't recall everhaving a manual for it (cannot find it anyway!). All I could findon the modem itself was 560 DTV (data voice fax), fortunatelyI did manage to track it down from just this info.http://www.hhosting.co.uk/modtech/support/AMBsupp.htm Nope, wrong chipset, wrong modem type. This is an *external* modem using an Ambient/Intel/Cirrus Logic chipset. You stated elsewhere that yours was an *internal*.If I did do that (I don't recall) I did it in error, its the correct modemalright.

You *did* do that. It's in the Google archives. In any case, unless
the Ambient AT command documentation is incorrect, the AT&V1 results
you posted are *not* those of an Ambient modem. Rather, they look like
Conexant/Rockwell data. In fact the data are very similar to that
produced by my own Rockwell modem, after it has been reset.

at&v1
TERMINATION REASON.......... NONE
LAST TX rate................ N/A
HIGHEST TX rate............. 300 BPS
LAST RX rate................ N/A
HIGHEST RX rate............. 300 BPS
PROTOCOL.................... N/A
COMPRESSION................. N/A
Line QUALITY................ 255
Rx LEVEL.................... 215
Highest Rx State............ 00
Highest TX State............ 00
EQM Sum..................... FFFF
RBS Pattern................. FF
Rate Drop................... FF
Digital Loss................ None
Local Rtrn Count............ 00
Remote Rtrn Count........... 00
Flex fail

OK
I am fairly sure of that, (maybe a different case), they only do a fewmodems.

Follow the next two links and you will find out exactly which modem(s)
you have. In the meantime go to Control Panel -> Diagnostics -> More
Info and capture the ATIn responses. ATI6 and ATI3 identify
Rockwell/Conexant chipsets and firmware revisions.
Identifying Your Chipset http://www.modemsite.com/56k/chipset.asp Who Manufactured My Modem? http://www.modemsite.com/56k/whomadeit.asp
I have the proper .inf file now I think, Mdmcir.inf I doubt it. This is probably an INF for a Cirrus Logic chipset. Cirrus Logic became Ambient, and then Ambient was absorbed by Intel.No its the right one. Mine is an old modem.Definately the right one.

External modems will probably still "work" with the "wrong" INF file,
they just may not work optimally.
(there is also aSerwvcir.inf file too). I am not sure how to 'install' this though,I was thinking I could just replace the contents of the existing .inffile (although I forget its name (I am sure you or I mentioned it in thisthread somewhere?)) mdmcomm1.inf mdmcom1.inf?? No. You must uninstall the current modem and then install the new one. The installation process loads driver files (*.vxd) and rewrites the registry.Can't I have several modems?

Yes, you can. But you can't just overwrite an INF file and expect it
to change anything. An INF file is only used during the installation
process - it can be deleted after the modem has been installed. DUN
never looks at it again.
I assume this is the bit where you hear the characteristic screechingtones? as it tries higher and higher baud rates? It's not trying higher "baud rates". The modems are sending different frequencies down the phone line and assessing the line's frequency response, among other things.Well basically the same thing, finding the best baud rate to use"trying higher baud rates"

You are mangling the terminology. Do a Google search on "baud rate" to
see what the term really means.
No, the default is V.42 LAPM and V.42bis.Whatever. The default doen't matter too much, what matters is how the modemis configured. Which is what I am trying to find out.

There is nothing in your modemlog to say that the modem is configured
with anything other than default parameters. Post the full modemlog so
we can see the init strings.
Your post-call diagnostics will tell you the error rates and the numbers of speedshifts and retrains (see my other post).Which one? the reason i am doing this is because I cannotsee such data in the first place!!

Follow the links I gave you. Once again, DUN is resetting your modem's
diagnostic data. You need to edit the Reset parameter in your
registry. Try the AT&V1, AT&V2, AT#UG, AT#UD, ATI6, ATI11, ATY11
diagnostic commands. One or more should apply to your modem, the
others will return an ERROR.
Modem log.

There are some missing lines here. They show the name of your modem's
INF file, and also the init strings.
07-01-2004 21:45:26.89 - Recv: ATE0V1<cr>07-01-2004 21:45:26.89 - Recv: <cr><lf>OK<cr><lf>07-01-2004 21:45:26.89 - Interpreted response: Ok07-01-2004 21:45:26.89 - Send: ATX4<cr>07-01-2004 21:45:26.89 - Recv: <cr><lf>OK<cr><lf>07-01-2004 21:45:26.89 - Interpreted response: Ok07-01-2004 21:45:26.90 - Dialing.07-01-2004 21:45:26.90 - Send: ATDT###########<cr>07-01-2004 21:45:48.27 - Recv: <cr>07-01-2004 21:45:48.27 - Interpreted response: Informative07-01-2004 21:45:48.27 - Recv: <lf>07-01-2004 21:45:48.27 - Interpreted response: Informative07-01-2004 21:45:48.28 - Recv: CONNECT 57600

Your modem is configured to report the DTE rate rather than the DCE
rate. This information is basically useless because it tells you
nothing about the speed of your connection. Worse still, setting the
DTE rate to such a low value limits your transfer rate to 5.76KB/s.
This means that you will never realise the full benefits of hardware
compression. I don't know where you got your claimed throughput
figures of 6.2KB/s, 35KB/s, and 25.4KB/s, unless you have accidentally
enabled software compression, assuming your ISP supports this feature.
Or were those figures achieved with another modem?
07-01-2004 21:45:48.28 - Interpreted response: Connect07-01-2004 21:45:48.28 - Connection established at 57600bps.07-01-2004 21:45:48.28 - Error-control off or unknown.07-01-2004 21:45:48.28 - Data compression off or unknown.

If you have a Rockwell/Conexant chipset, add S95=45 to DUN's Extra
Settings. This will enable CONNECT, CARRIER, PROTOCOL, and COMPRESSION
reports.

And set the port rate to 115200bps.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.

[half_pint]

"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in message
news:ad5ue0t6ubhasjvf68k68mk5gj83jplte8@4ax.com... On Thu, 8 Jul 2004 23:01:24 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed:"Franc Zabkar" <fzabkar@optussnet.com.au> wrote in messagenews:cbbre092bssevqg6h1kvrtfiuhbu9dv6ve@4ax.com... On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint" <esboella.arse@yahoo.com> put finger to keyboard and composed: Sorry, but you haven't been right about much, if anything, so far.In your opinion. Usenet is full of opinions and disinformation. That's why I support my statements with authoritative references wherever possible. Even so, I'm prepared to be proven wrong. Show me your data.You don't now how my modem is configured, so basically you are clutching
atstraws. You are talking about error correction and protocols when you
don'tknow how my modem or the OP's is configured. Until a few days ago you hadn't even heard of error correction and data compression, yet now you are offering opinions on same.

No, a few days ago you made that assumption, along with several other
assumptions which were incorrect.
>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 Highly unlikely. You snipped out the important data just prior to these two lines.Wrong I snipped out nothing important, see the log at the end of file. The log shows that you do not understand how to properly configure a modem.

No it doesn't all it shows it what was written to it.
Anyway I didnt configure my modem as it happens it was preconfigured.

>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 Nope, wrong chipset, wrong modem type. This is an *external* modem using an Ambient/Intel/Cirrus Logic chipset. You stated elsewhere that yours was an *internal*.If I did do that (I don't recall) I did it in error, its the correct
modemalright. You *did* do that. It's in the Google archives.
Which you conviently have 'lost'?

In any case, unless the Ambient AT command documentation is incorrect, the AT&V1 results you posted are *not* those of an Ambient modem. Rather, they look like Conexant/Rockwell data. In fact the data are very similar to that produced by my own Rockwell modem, after it has been reset. at&v1 TERMINATION REASON.......... NONE LAST TX rate................ N/A HIGHEST TX rate............. 300 BPS LAST RX rate................ N/A HIGHEST RX rate............. 300 BPS PROTOCOL.................... N/A COMPRESSION................. N/A Line QUALITY................ 255 Rx LEVEL.................... 215 Highest Rx State............ 00 Highest TX State............ 00 EQM Sum..................... FFFF RBS Pattern................. FF Rate Drop................... FF Digital Loss................ None Local Rtrn Count............ 00 Remote Rtrn Count........... 00 Flex fail OKI am fairly sure of that, (maybe a different case), they only do a fewmodems. Follow the next two links and you will find out exactly which modem(s) you have. In the meantime go to Control Panel -> Diagnostics -> More Info and capture the ATIn responses. ATI6 and ATI3 identify Rockwell/Conexant chipsets and firmware revisions.


I know which modem I have thank you very much, I dont fancy a wild goose cha
se.
Identifying Your Chipset http://www.modemsite.com/56k/chipset.asp Who Manufactured My Modem? http://www.modemsite.com/56k/whomadeit.asp >I have the proper .inf file now I think, Mdmcir.inf I doubt it. This is probably an INF for a Cirrus Logic chipset. Cirrus Logic became Ambient, and then Ambient was absorbed by Intel.No its the right one. Mine is an old modem.Definately the right one. External modems will probably still "work" with the "wrong" INF file, they just may not work optimally.


Modems will work most of the time as I have found, I have
configu