Modem connection speed
Neil Barnwell
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
provider and the isp provider to check it for you.
Art Leonard
Alex B
dial up (usually when fixing virus infected laptops in work).
"Art Leonard" <Kufu...@earthlink.net> wrote in message
news:Hw0Fc.1600$oD3...@newsread1.news.pas.earthlink.net...
DaveW
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" <neilba...@hotmail.com> wrote in message
news:cc20ul$k2u$1...@newsg3.svr.pol.co.uk...
yak
says...
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" <neilba...@hotmail.com> wrote in message
news:cc20ul$k2u$1...@newsg3.svr.pol.co.uk...
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 />
>
>
>
ChrisJ9876
>Date: 07/02/2004 2:38 PM Eastern Daylight Time
>Message-id: <2klo83F...@uni-berlin.de>
half_pint
"ChrisJ9876" <chris...@aol.comnospam> wrote in message
news:20040702164057...@mb-m10.aol.com...
Well maybe, it depends on how the data rate is calculated if for instance
you go
to
http://start.maui.net/home/techsupport/bandwidth/image1.htm
You will find your speed is determined simply by dividing the size of the
image in bytes by the time taken (X8), however as I use a stop bit it should
be X9.
Also there will be a start bit two so it is X10 so......if I get the max
data rate 56kbs and they use their image size over time method all
is not as it seems, because 10 bit are transmitted for every 8 counted.
So the speed is 20% higher in reality.
Then of course there is the overhead of internet protocols to take into
account.
Also if you look at dial up networking bytes sent this is not going to
include start and stop bits.
I would imagine most phone lines are easilly capable of 56kps, I
mean when you upgrade to broadband they dont change the line of
they?
They dont lay down a whole new wire back to the exchange, its the
same line isn't it?
And those lines will be doing 10 times 56 kps (or 40X's in some cases).
Alex B
max of 56kb/s ;-)
"half_pint" <esboel...@yahoo.com> wrote in message
news:2km2h0F...@uni-berlin.de...
half_pint
"Alex B" <Freef...@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
half_pint
"DaveW" <no...@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
half_pint
"Alex B" <Freef...@hotmail.com.NOSPAM> wrote in message
news:cc25ac$65l$1...@news7.svr.pol.co.uk...
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?
half_pint
I am aware it is 56 kbits/second so what are you on about??????
"Alex B" <Freef...@hotmail.com.NOSPAM> wrote in message
news:cc4n6j$lr4$1...@newsg3.svr.pol.co.uk...
half_pint
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" <Kufu...@earthlink.net> wrote in message
news:Hw0Fc.1600$oD3...@newsread1.news.pas.earthlink.net...
Alex B
...]
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
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.
Franc Zabkar
<esboell...@yahoo.com> put finger to keyboard and composed:
>
>"Alex B" <Freef...@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,
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 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. :-)
half_pint
"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
news:5shce05edlrrmv5q6...@4ax.com...
> On Fri, 02 Jul 2004 23:34:31 GMT, "half_pint"
> <esboell...@yahoo.com> put finger to keyboard and composed:
>
> >
> >"Alex B" <Freef...@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,
>
> 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
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
half_pint
I've seen them, I forgot about the start bit here but i corrected that in a
slightly later
post. See my response.
half_pint
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.
ric
> >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.
>
> 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" <nos...@home.com> wrote in message news:40E709F5...@home.com...
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
I bet you have them rolling in the isles with wit like that :O|
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
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.
half_pint
I am sorry I am really not to sure what you are on about,
what have start and stop bits got to do with error correction?
Nothing whatsoever as far as I am concerned.
You will have to explain yourself better as I am not sure
what error correction you are on about.
As far as I can see there is no option to 'disable error
connection' in internet options, you can forget Hyperterminal
because I don't use it (as far as I am aware) and neither does the OP.
So i am not really to sure what you are getting at because when I
look at my modem properties is says 8 data, 1 stop bit and no
parity bit (I presume the start bit is taken for granted).
Because it says this I have to believe what I see and take it
as fact as that is what the modem is doing.
If it was configured otherwise I am sure it would say so.
If you can show me a link which clearly shows that these value
are not used I would like to see it.
As I said your Hyper Terminal experiments are not really relevant
as far as I can see.
The utility I mentioned in this thread shows me receiving data at 6.2KBs
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
>
> 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!!
Franc Zabkar
Exactly. Yet it is you who has introduced irrelevant start and stop
bits to "explain" modem-to-modem transfer rates. What I am saying is
that the only time modems transfer start and stop bits between each
other is on those very rare occasions they have been unable to
negotiate an error corrected link. At all other times these bits are
discarded.
>You will have to explain yourself better as I am not sure
>what 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 error
>connection' 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 Hyperterminal
>because 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 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.
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 value
>are 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 relevant
>as 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.
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
<esboel...@yahoo.com> put finger to keyboard and composed:
>Incidently the utility I am using shows me receiveing data at 7.3 KBs
>which 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
<esboel...@yahoo.com> put finger to keyboard and composed:
>
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.
half_pint
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 sure
> >what 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 error
> >connection' 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 Hyperterminal
> >because 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 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.
>
> 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 value
> >are 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 relevant
> >as 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.
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.
half_pint
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?
Gary D.
<neilba...@hotmail.com> 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 />
>
>
I previously suffered with an almost identical problem, although apart
from slow connection speeds my main issue was random disconnections.
My ISP suggested a few things, including contacting my phone company
and asking them to increase the line gain from the standard 1 to the
maximum of 3.
However, this is fine with a clean line but with a noisy line will
only increase the noise and also increase the likelihood of random
disconnections, so first get the noise problem sorted out.
When my phone company examined my nearest public routing/junction
cabinet the engineer discovered that during heavy rainfall the water
had been seeping into the cabinet and had gradually eroded some of the
contacts; these were replaced and the line gain was increased to its
maximum and now I connect at 50667bps for 90% of the time (49333bps
the rest of the time). The connection rate is also now much more
stable with only an occasional random disconnection.
I live in the UK by the way.
Don't know if any of this info helps?
PS. I'm using Windows98 with an internal "Conexant HCF V90 56K Data
Fax RTAD PCI Modem". I've also used a "Rockwell 56K ACF II
Fax+Data+Voice Modem" (external) with so-so results.
---
You're never alone with schizophrenia!
half_pint
"Gary D." <nos...@crap.null.net> wrote in message
news:s15me0hq3heq3c1eb...@4ax.com...
It might also be worth him checking inside the telephone sockets inside
his home as water and condensation can get inside and corode the contacts,
or make false connections across them.
I had this happen to me, the engineer chased a noisy line down to corosion
inside one of the sockets.
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>
>"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>news:nhshe018jqsvpb1n4...@4ax.com...
>> On Mon, 5 Jul 2004 03:35:30 +0100, "half_pint"
>> <esboel...@yahoo.com> put finger to keyboard and composed:
>>
>> >Incidently the utility I am using shows me receiveing data at 7.3 KBs
>> >which 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
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 sure
>> >what 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 error
>> >connection' 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.
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 Hyperterminal
>> >because 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 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.
>>
>> 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.
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 value
>> >are 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.
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 relevant
>> >as 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.
On the contrary, your testing methodology produces results which
cannot be reproduced by anyone, not even yourself. We have no idea as
to the data type, the speed of your connection, the Tx/Rx error rates,
whether there is any network congestion, whether you are using S/W or
H/W compression (MNP, V42bis, V44), which protocols you are using (eg
V.90 or V.92), etc, etc.
In fact, as a direct result of my controlled testing, it is obvious
that I can achieve slightly better throughput (~2%) by forcing my
modem to negotiate an MNP/V.42bis connection as opposed to the default
of V.42/V.42bis. This is because V.42 EC limits my modem to 128 byte
blocks whereas MNP gives me the option of 256 bytes. Using Sysmon to
monitor the download rate for a ZIP file at a sustained speed of
46667bps (confirmed by post-call diagnostics), I have improved the
throughput from 5.3KB/s to 5.4KB/s. I did this by adding "\N5 %C2 \A3"
to DUN's Extra Settings.
At 6.2KB/s that would equate to a DCE rate of around 52000bps. I doubt
that you are achieving this kind of connection. To find out either
way, dump the modem's post-call diagnostic report. See my other post
in this thread for instructions on how to do this.
>> 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 what
>rate bits are being transmitted at as anything else is pretty meaning less.
Actually, from a user's perspective, *throughput* is the most
important thing.
half_pint
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!!)
Gary D.
Just remembered something else!
I have been informed that if there are several communications devices
connected sharing the same line (eg. PC, phone, fax) then by
disconnecting all others when your PC's modem is being used, this can
apparently improve connection speeds.
Try it!
I don't know the exact reason why this should work, but I'm guessing
it may be something to do with the other devices having to process
(and ignore) the noise generated by the modem signal.
half_pint
When I asked BT about my bad line they always asked how many
devices were connected to it, I suppose the less things you have connected
the less chance you have of one of them being faulty? Also I think a battery
at the exchange provides power for the phone(s)? maybe there is a limit as
to
how many devices you can have connected?
Zotin Khuma
Living in a remote corner of India, I thought almost everyone in the
more advanced countries would be using at least >128Kb/s cable/DSL.
Here's my 2 cents worth from an end-user's POV.
My phone company is also my ISP and I happen to live less than 200
metres from their building, though the actual line length is probably
about twice that. I've used several different modems and never
bothered to use anything other than the generic Windows drivers. Max
connection speed setting is limited to 115K, and I often manage to
connect at that speed, though it's sometimes at 33k or even lower.
The connecting speed doesn't seem to greatly determine the actual
download speed. I may connect at 115k and still have to wait for ages
for web pages to open, or connect at 33k another time and have the
same website move at relatively blazing speeds.
File download speeds as shown by IE or Download Accelerator vary from
less than 0.1 kiloBYTES/s to about 4.5kB/s on a very good day. These
are sustained speeds, not burst speeds which sometimes shoot up to
20kB/s at the start of a file download. The primarily cause of the
large variation in speed does not seem to be the state of my phone
line (though this must certainly be a factor), but rather from the
server since friends in other parts of the town usually experience
corresponding variations at the same time.
Another factor that took some time to track down was one particular
computer's PSU. It caused connection problems, random disconnections,
etc., but ONLY when my phone line was unusually noisy. Replacing the
PSU cured it completely. It never posed any problem in off-line
computing.
BTW, one of the "advantages" of living in a less developed region is
that the phone company doesn't seem to mind if I repair or tweak my
own line. Twice in the past 10 years or so, I've bought phone cable
from a store and completely replaced the overhead lines from their
junction box. Fibre-optic has not completely replaced metal here.
Noozer
> When I asked BT about my bad line they always asked how many
> devices were connected to it, I suppose the less things you have connected
> the less chance you have of one of them being faulty? Also I think a
battery
> at the exchange provides power for the phone(s)? maybe there is a limit as
> to
> how many devices you can have connected?
Definately
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>This thread/posts have became a bit long so I though I would start
>afresh
Excellent idea.
>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.
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 modem
>at the moment (more on that later), as I am fairly sure I am getting
>better 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 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.
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 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*.
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 aware
>I will destroy the modem if I screw-up up when updating its flash
>memory. (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 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??
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 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).
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 screeching
>tones? 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 badly
>designed 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 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!
No, the default is V.42 LAPM and V.42bis.
>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!!
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.
half_pint
"Zotin Khuma" <zot...@rediffmail.com> wrote in message
news:304fc392.04070...@posting.google.com...
Well I live in the UK and most people still use dial-up 56k modems
although broadband is available if you are willing to pay more
( the prices are set by British Telecom (BT) which is a virtual monopoly so
basically they can charge what they like, there are some cable
companies but they are just as expensive)
> Here's my 2 cents worth from an end-user's POV.
>
> My phone company is also my ISP and I happen to live less than 200
> metres from their building, though the actual line length is probably
> about twice that. I've used several different modems and never
> bothered to use anything other than the generic Windows drivers. Max
> connection speed setting is limited to 115K, and I often manage to
> connect at that speed, though it's sometimes at 33k or even lower.
>
> The connecting speed doesn't seem to greatly determine the actual
> download speed. I may connect at 115k and still have to wait for ages
> for web pages to open, or connect at 33k another time and have the
> same website move at relatively blazing speeds.
>
> File download speeds as shown by IE or Download Accelerator vary from
> less than 0.1 kiloBYTES/s to about 4.5kB/s on a very good day.
I usually can get about 4.4 is the site is not busy, you might as well have
56k dial-up as your max speed is no better than mine. no real point if you
are paing more for ISDN and getting a dial-up speed. (Actually I am unsure
what you have and you may have dial-up, your "connect at 115k maybe
misleaeding you (computer to modem speed, not modem to modem speed?)
>These
> are sustained speeds, not burst speeds which sometimes shoot up to
> 20kB/s at the start of a file download. The primarily cause of the
> large variation in speed does not seem to be the state of my phone
> line (though this must certainly be a factor), but rather from the
> server since friends in other parts of the town usually experience
> corresponding variations at the same time.
Well I expect your line is perfect and you are hitting the local
internet 'rush-hour' where everyone wants a slice of your
ISP's available bandwith, obviously it had not bought
enough bandwith to cope at peak times. (I had an ISP
whhich did this and it was very slow at peak times).
>
> Another factor that took some time to track down was one particular
> computer's PSU. It caused connection problems, random disconnections,
> etc., but ONLY when my phone line was unusually noisy. Replacing the
> PSU cured it completely. It never posed any problem in off-line
> computing.
Your PSU may have been interferring with with your phone line,
it might have been creating a lot of electrical 'noise' which could
affect your line, especially if it had some poor connections etc..
>
> BTW, one of the "advantages" of living in a less developed region is
> that the phone company doesn't seem to mind if I repair or tweak my
> own line. Twice in the past 10 years or so, I've bought phone cable
> from a store and completely replaced the overhead lines from their
> junction box.
I doubt BT has touched my line in the 30 years it has been in exixtance!!!
Personally I doubt your line is the problem, the best way to test it is
to pick up the phone and listen. If they used the correct cable in the
first place I cannot see why you would be getting a problem.
I thought I had a bad line and it turned out to be moisture
in a socket, all the while I was looking at the cable around my house
and thinking "I bet thats all corroded inside!!"
>Fibre-optic has not completely replaced metal here.
Nor here, I expect BT will be using the same copper
wires for the next 20 years or so.
half_pint
> On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint"
> <esboel...@yahoo.com> put finger to keyboard and composed:
>
> >This thread/posts have became a bit long so I though I would start
> >afresh
>
> Excellent idea.
>
> >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.
>
> 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
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.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 aware
> >I will destroy the modem if I screw-up up when updating its flash
> >memory. (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 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??
>
> 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?
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=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 badly
> >designed 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 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!
>
> 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 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!!
>
> 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
<esboel...@yahoo.com> put finger to keyboard and composed:
>
>"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>news:cbbre092bssevqg6h...@4ax.com...
>> On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint"
>> <esboel...@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 at
>straws. You are talking about error correction and protocols when you don't
>know 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 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 modem
>alright.
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 few
>modems.
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 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??
>>
>> 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 screeching
>> >tones? 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 modem
>is 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 cannot
>see 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: 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
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: 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.
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.
half_pint
> On Thu, 8 Jul 2004 23:01:24 +0100, "half_pint"
> <esboel...@yahoo.com> put finger to keyboard and composed:
>
> >
> >"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
> >news:cbbre092bssevqg6h...@4ax.com...
> >> On Thu, 8 Jul 2004 03:18:25 +0100, "half_pint"
> >> <esboel...@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
at
> >straws. You are talking about error correction and protocols when you
don't
> >know 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
modem
> >alright.
>
> You *did* do that. It's in the Google archives.
Which you conviently have 'lost'?
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
configured my modem as several different types and it still works
(33k 56k flex) (it runs 6.2 KB at 33k).
The basic stuff will work, the 'fancy' unnecessary stuff might not, but
who cares?
>
> >> >(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??
> >>
> >> 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.
Well I have 3 modems set up alreaaaady anyway.
>
> >> >I assume this is the bit where you hear the characteristic screeching
> >> >tones? 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.
I know what it means, do a google search on 'intelligence'.
>
> >> 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.
>
> 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.
I posted it all, anymore would just be repeations of the same info.
>
> >> 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!!
>
> 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.
I tried them all and they dont produce anything useful.
>
> >Modem log.
>
> There are some missing lines here. They show the name of your modem's
> INF file, and also the init strings.
No your're wrong there.
>
> >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
>
> 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?
No obviously not, maybe you do not understand how these figures
were calculated? Anyway I am receiving compressed data in the first
place, it wont compress any futher.
>
> >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.
>
> 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.
I set it to that ages ago.
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
... a whole lotta ignorant drivel.
It's clear that you're too stupid and too arrogant to take on board
any new information. You can't comprehend simple arithmetic, you can't
follow instructions, you don't even know what kind or how many modems
you have. BTW, "internal" means "inside" the box, "external" is
"outside".
Here are some thoughts to ponder as you grow up and prepare to enter
the real world.
"Take the attitude of a student. Never be too big to ask questions.
Never know too much to learn something new."
- Og Mandino (1923- )
"A man should never be ashamed to own he has been in the wrong, which
is but saying, in other words, that he is wiser today than he was
yesterday."
- Alexander Pope (1688-1744)
<your ignorant drivel snipped>
half_pint
And here is one for you
"Try not to be a sore loser" - Anon (10/07/2004 10:50PM GMT.).
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>
>"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>news:1vk0f0d7ob661ndlb...@4ax.com...
>> On Sat, 10 Jul 2004 01:02:55 +0100, "half_pint"
>> <esboel...@yahoo.com> put finger to keyboard and composed:
>>
>> ... a whole lotta ignorant drivel.
>>
>> It's clear that you're too stupid and too arrogant to take on board
>> any new information. You can't comprehend simple arithmetic, you can't
>> follow instructions, you don't even know what kind or how many modems
>> you have. BTW, "internal" means "inside" the box, "external" is
>> "outside".
>>
>> Here are some thoughts to ponder as you grow up and prepare to enter
>> the real world.
>>
>> "Take the attitude of a student. Never be too big to ask questions.
>> Never know too much to learn something new."
>>
>> - Og Mandino (1923- )
>>
>> "A man should never be ashamed to own he has been in the wrong, which
>> is but saying, in other words, that he is wiser today than he was
>> yesterday."
>>
>> - Alexander Pope (1688-1744)
>>
>> <your ignorant drivel snipped>
>
>
>And here is one for you
>
>"Try not to be a sore loser" - Anon (10/07/2004 10:50PM GMT.).
Unlike you, I don't see Usenet as an ego trip. In fact I don't have
any problem admitting to error, even when the other party is someone I
detest.
To remove any such doubt, see this post ...
http://groups.google.com/groups?selm=fuqovvsqfcp4q5kppa36i218jp5op4ghhm%404ax.com&output=gplain
... in which I state ...
"I may not like you [an antagonist who is prone to profanity and
racial slurs], but that does not prevent me from acknowledging
you when you are right. I have no ego to protect, and I in no way feel
diminished when I confess my ignorance, especially if I can learn
something in the process."
BTW, the difference between ignorance and stupidity is that the former
can be remedied through education. The latter requires surgery.
half_pint
No lets face it, you said I was wrong, but I wasn't Stop and start bits
are sent.
Good luck with the surgery.
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>> BTW, the difference between ignorance and stupidity is that the former
>> can be remedied through education. The latter requires surgery.
>
>
>No lets face it, you said I was wrong, but I wasn't Stop and start bits
>are sent.
>
>Good luck with the surgery.
You have the intelligence of a gnat. What is it about the following
that you don't understand?
http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html
"Top-speed V.34 modems use V.42 error control. When V.42 error control
is used [which is *all* the time unless something is seriously wrong],
NO START OR STOP BITS ARE SENT over the line."
half_pint
> On Sun, 11 Jul 2004 18:49:37 +0100, "half_pint"
> <esboel...@yahoo.com> put finger to keyboard and composed:
>
> >> BTW, the difference between ignorance and stupidity is that the former
> >> can be remedied through education. The latter requires surgery.
> >
> >
> >No lets face it, you said I was wrong, but I wasn't Stop and start bits
> >are sent.
> >
> >Good luck with the surgery.
>
> You have the intelligence of a gnat. What is it about the following
> that you don't understand?
>
> http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html
>
> "Top-speed V.34 modems use V.42 error control. When V.42 error control
> is used [which is *all* the time unless something is seriously wrong],
> NO START OR STOP BITS ARE SENT over the line."
They are still sent from the DTE to the DCE though. At least according
to the setting in IE, microsoft could have made an error there of course,
but if they did then you really have to take all their other settings with
a pinch of salt.
So if I am wrong then I am in good company (well maybe not if it is
microsoft).
You are also making assumptions about the protocol used, but that
is a minor point given the above
Do you know mine and the OP's settings?
I can't find out what mine are at the monent anyhow.
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>news:52d3f09dvaccbbrg7...@4ax.com...
>>What is it about the following
>> that you don't understand?
>>
>> http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html
>>
>> "Top-speed V.34 modems use V.42 error control. When V.42 error control
>> is used [which is *all* the time unless something is seriously wrong],
>> NO START OR STOP BITS ARE SENT over the line."
>
>
>They are still sent from the DTE to the DCE though.
Of course they are, at least for external serial (non-USB) modems. But
these extra bits have no impact upon the modem's connect speed, nor do
they affect the throughput for incompressible data, if the port rate
has been configured correctly. And therein lies the reason for your
fixation regarding this issue. If your more recent posts are any
guide, then it is clear that you have been restricting yourself to a
DTE rate of only 57600bps since the first day you installed your
modem. This would have limited you to a max throughput of only
5.76kB/s, which would mean that your COM port is throttling your
modem's performance. At 5.76kB/s and 8.20 bits/byte (according to my
testing), this amounts to only 47232bps. OTOH, a COM port that is
correctly configured for 115200bps would be subject to no such
limitations, even at a theoretical maximum DCE rate of 56000bps. In
any case, there is nothing to prevent a modem from *connecting* at a
DCE rate higher than its DTE rate.
This post demonstrates why it is silly to limit your port rate to
57600bps as you have done:
http://groups.google.com/groups?selm=VKjW9.1855%24zF6.155226%40bgtnsc04-news.ops.worldnet.att.net&output=gplain
> At least according
>to the setting in IE,
Your browser has absolutely no control over your modem settings. You
can access these via DUN or via Control Panel -> Modems or via Device
Manager.
>microsoft could have made an error there of course,
No errors, just a very basic, no frills, generic, chipset based INF
file.
>but if they did then you really have to take all their other settings with
>a pinch of salt.
>So if I am wrong then I am in good company (well maybe not if it is
>microsoft).
>
>You are also making assumptions about the protocol used, but that
>is a minor point given the above
No. Your modemlog shows that you have added nothing to your modem's
Extra Settings. You have also stated that your EC and compression
check boxes were greyed out. This proves that your modem is operating
with its default settings. These defaults include V.90, V.42, and
V.42bis.
>Do you know mine and the OP's settings?
I know enough about your settings to know that they are far from
optimal. At the very least you should increase your port rate to
115200bps, for performance reasons. You would also benefit from
knowing your actual connect speed, eg 44000bps, rather than having DUN
tell you what you already know, ie that you port rate is 57600bps.
>I can't find out what mine are at the monent anyhow.
I've shown you how, but you appear to be unable and unwilling to
follow instructions.
Follow my links to modemsite.com and learn something about your modem,
as I have done. You could also post your questions to comp.dcom.modems
where there are a lot more knowledgeable people than you or I.
half_pint
> On Mon, 12 Jul 2004 03:47:02 +0100, "half_pint"
> <esboel...@yahoo.com> put finger to keyboard and composed:
>
> >"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
> >news:52d3f09dvaccbbrg7...@4ax.com...
>
> >>What is it about the following
> >> that you don't understand?
> >>
> >> http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html
> >>
> >> "Top-speed V.34 modems use V.42 error control. When V.42 error control
> >> is used [which is *all* the time unless something is seriously wrong],
> >> NO START OR STOP BITS ARE SENT over the line."
> >
> >
> >They are still sent from the DTE to the DCE though.
>
> Of course they are, at least for external serial (non-USB) modems. But
> these extra bits have no impact upon the modem's connect speed, nor do
> they affect the throughput for incompressible data, if the port rate
> has been configured correctly. And therein lies the reason for your
> fixation regarding this issue. If your more recent posts are any
> guide, then it is clear that you have been restricting yourself to a
> DTE rate of only 57600bps since the first day you installed your
> modem.
Wrong firstly I didn't install my modem it was pre installed.
Secondly there is no ability to set the DTE setting, I can set the
modem to run at its correct rated speed 57600bps of course.
Actually I may well be wrong about the above as I have found
the setting for comm1, my modem port and it was actually
set to 9600. (control panel - system - devivce manager).
Not that that low setting appeared to throttle my modem
which makes most of the folling bumf irrelevant.
Do you recommend trying to run modems at twice their rated speeds?
> This would have limited you to a max throughput of only
> 5.76kB/s, which would mean that your COM port is throttling your
> modem's performance. At 5.76kB/s and 8.20 bits/byte (according to my
> testing), this amounts to only 47232bps. OTOH, a COM port that is
> correctly configured for 115200bps would be subject to no such
> limitations, even at a theoretical maximum DCE rate of 56000bps. In
> any case, there is nothing to prevent a modem from *connecting* at a
> DCE rate higher than its DTE rate.
>
> This post demonstrates why it is silly to limit your port rate to
> 57600bps as you have done:
Those were are modem settings.
>
http://groups.google.com/groups?selm=VKjW9.1855%24zF6.155226%40bgtnsc04-news.ops.worldnet.att.net&output=gplain
>
>
> > At least according
> >to the setting in IE,
>
> Your browser has absolutely no control over your modem settings.
Internet options etc....
>You
> can access these via DUN or via Control Panel -> Modems or via Device
> Manager.
>
> >microsoft could have made an error there of course,
>
> No errors, just a very basic, no frills, generic, chipset based INF
> file.
>
> >but if they did then you really have to take all their other settings
with
> >a pinch of salt.
> >So if I am wrong then I am in good company (well maybe not if it is
> >microsoft).
> >
> >You are also making assumptions about the protocol used, but that
> >is a minor point given the above
>
> No. Your modemlog shows that you have added nothing to your modem's
> Extra Settings. You have also stated that your EC and compression
> check boxes were greyed out. This proves that your modem is operating
> with its default settings. These defaults include V.90, V.42, and
> V.42bis.
No all it proves it that they are blanked out.
>
> >Do you know mine and the OP's settings?
>
> I know enough about your settings to know that they are far from
> optimal. At the very least you should increase your port rate to
> 115200bps, for performance reasons.
My modem is 56k I have increased my comm1 port setting to 115200
however I dont think it really cares what you set it to.
>You would also benefit from
> knowing your actual connect speed, eg 44000bps, rather than having DUN
> tell you what you already know, ie that you port rate is 57600bps.
>
> >I can't find out what mine are at the monent anyhow.
>
> I've shown you how, but you appear to be unable and unwilling to
> follow instructions.
Nobody tell me what to do, not unless you are paying a decent hourly rate.
You instructuions failed anyhow.
>
> Follow my links to modemsite.com and learn something about your modem,
> as I have done.
I dont take orders.
half_pint
> >You are also making assumptions about the protocol used, but that
> >is a minor point given the above
>
> No. Your modemlog shows that you have added nothing to your modem's
> Extra Settings. You have also stated that your EC and compression
> check boxes were greyed out. This proves that your modem is operating
> with its default settings. These defaults include V.90, V.42, and
> V.42bis.
>
I actually have a disc which was supplied with my computer, which has some
sort of modem upgrade on it (v90 upgrade) however it is not a very good
disc (scratches or dirt) and I have great difficulty reading it.
I have however managed to recover some of the data off it (about 1/3 so far)
(sometimes my computer wont read it at all) anyway
=================
\N Error Correction Operating Mode
Parameter: \N0: Standard operation (non error-corrected, buffered data).
\N1: Direct operation (non error-corrected, data not buffered).
\N2: Reliable operation (MNP). If the modem fails to negotiate a
reliable connection it will drop the call.
\N3: Auto-Reliable operation (V.42 or MNP). If the modem fails to negotiate
a reliable connection it will adopt a standard connection as fallback.
\N4: Enable MNP error correction only.
\N5: Enable LAP-M error correction only.
Default: \N3
Purpose: To specify which error correction negotiation will occur after
carrier is established.
===============
So it is not too clear what is happening as N0 is standard and N3 is
default, i suspect N3
but as I cannot get meaningful data from my modem I canot be 100%.
Actually I did manage to install it (or something), I selected the
american english (as opposed to english english) instalation and
it went through and installed something called supervoice.
When I tried the english version I got 'cannot open file' errors.
However I don't think it installed the 'upgrade', but I managed
to copy off the the files in upgrade\external which is what I want
I think. When I try to get upgrade\internal it tends to lock my computer
up but I should not need anything in there anyway.
There is a setup.bat and a v90wiz.exe in the external folder so hopefully
I have enough files copied off to do it.
Anyway I will try the upgrade later. If I cannot get back on line
(wouldn't that be nice eh?) you will know why and obviously
be delighted!!!
Mind up even if it does install I doubt I will notice any difference
whatsoever. I can currently down load about 20megs an hour
on a good day (of compressed data and i doubt I will see any
improvement on that!
half_pint
"half_pint" <esboel...@yahoo.com> wrote in message
news:2lh1uaF...@uni-berlin.de...
Tried that but it doesn't recognise the modem. Maybe the modem
doesn't need it.
Franc Zabkar
<esboel...@yahoo.com> put finger to keyboard and composed:
>
>"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>news:1gn5f0977eij1lluq...@4ax.com...
>> On Mon, 12 Jul 2004 03:47:02 +0100, "half_pint"
>> <esboel...@yahoo.com> put finger to keyboard and composed:
>>
>> >"Franc Zabkar" <fza...@optussnet.com.au> wrote in message
>> >news:52d3f09dvaccbbrg7...@4ax.com...
>>
>> >>What is it about the following
>> >> that you don't understand?
>> >>
>> >> http://www.nwfusion.com/archive/1995/95-04-03isdn-a.html
>> >>
>> >> "Top-speed V.34 modems use V.42 error control. When V.42 error control
>> >> is used [which is *all* the time unless something is seriously wrong],
>> >> NO START OR STOP BITS ARE SENT over the line."
>> >
>> >
>> >They are still sent from the DTE to the DCE though.
>>
>> Of course they are, at least for external serial (non-USB) modems. But
>> these extra bits have no impact upon the modem's connect speed, nor do
>> they affect the throughput for incompressible data, if the port rate
>> has been configured correctly. And therein lies the reason for your
>> fixation regarding this issue. If your more recent posts are any
>> guide, then it is clear that you have been restricting yourself to a
>> DTE rate of only 57600bps since the first day you installed your
>> modem.
>
>Wrong firstly I didn't install my modem it was pre installed.
Then the person who installed it is just as ignorant as yourself.
>Secondly there is no ability to set the DTE setting,
Millions of people have achieved this impossible task. With a little
knowledge and effort you can too.
> I can set the
>modem to run at its correct rated speed 57600bps of course.
The max "rated" DCE speed of a 56K modem is only 56000bps. OTOH, the
maximum rated DTE speed of hardware modems is at least 115200bps, and
can be as high as 230400bps. Soft modems can do even better. My own
hardware modem will report CONNECT 230400 when I configure it to
report the DTE speed, and it will have a throughput to match (for
highly compressible data). Yours will report CONNECT 115200 if you do
nothing more than select a port rate of 115200bps. Just look in the
INF file (assuming you have the correct one), or check the responses
at this registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Modem\000n\Responses
But please, whatever you do, DON'T do the following. Don't go to My
Computer -> Dial-Up Networking -> don't right click your ISP -> don't
select Properties -> Configure -> General -> Maximum speed. Instead,
just keep farting around with COM port Properties in Device Manager.
>Actually I may well be wrong about the above as I have found
>the setting for comm1, my modem port and it was actually
>set to 9600. (control panel - system - devivce manager).
>Not that that low setting appeared to throttle my modem
>which makes most of the folling bumf irrelevant.
What this proves is that you have no idea what you are doing or what
you are talking about. A COM port is a COM port, it is not a modem.
For example, I have one COM port to which I can attach any of four
serial devices via a switchbox. One is an external modem configured
for 115200bps, another is an old digital camera, a third is a DCC
connection to another PC, and the fourth is a Casio organizer running
at 9600bps. In each case it is not Device Manager that determines the
port speed, rather it is set by the application that takes control of
the COM port. All Device Manager does is to set some initial default
value.
>Do you recommend trying to run modems at twice their rated speeds?
You can't run a modem at twice its "rated speed", so the question is
pointless. Overclocking is for motherboards, not modems.
>> This would have limited you to a max throughput of only
>> 5.76kB/s, which would mean that your COM port is throttling your
>> modem's performance. At 5.76kB/s and 8.20 bits/byte (according to my
>> testing), this amounts to only 47232bps. OTOH, a COM port that is
>> correctly configured for 115200bps would be subject to no such
>> limitations, even at a theoretical maximum DCE rate of 56000bps. In
>> any case, there is nothing to prevent a modem from *connecting* at a
>> DCE rate higher than its DTE rate.
>>
>> This post demonstrates why it is silly to limit your port rate to
>> 57600bps as you have done:
>
>Those were are modem settings.
No, as I've explained to you elsewhere, you set up the COM port, and
the modem "autobauds" to these settings. So in effect you are
configuring the modem as a *consequence* of configuring the port. BTW,
I'm talking about configuring the COM port in the Modem Properties of
the DUN connectoid, not in Device Manager.
>http://groups.google.com/groups?selm=VKjW9.1855%24zF6.155226%40bgtnsc04-news.ops.worldnet.att.net&output=gplain
>>
>>
>> > At least according
>> >to the setting in IE,
>>
>> Your browser has absolutely no control over your modem settings.
>
>Internet options etc....
OK, I'll grant you that one, but strictly speaking it isn't IE that
modifies your connection parameters, it's Dial-Up Networking. IE
merely delegates the job to a Control Panel applet (Internet Options),
which in turn delegates it to DUN. A more direct route would be to go
to My Computer -> Dial-Up Networking. You can also access the Control
Panel applet by going to Start -> Run and typing "control
inetcpl.cpl".
The flow is something like this:
IE -> Control Panel -> Internet Options -> inetcpl.cpl -> DUN -> Modem
Properties
If you delete or rename the inetcpl.cpl file, then the only way to get
to Modem Properties is via DUN directly.
>>You
>> can access these via DUN or via Control Panel -> Modems or via Device
>> Manager.
>>
>> >microsoft could have made an error there of course,
>>
>> No errors, just a very basic, no frills, generic, chipset based INF
>> file.
>>
>> >but if they did then you really have to take all their other settings
>with
>> >a pinch of salt.
>> >So if I am wrong then I am in good company (well maybe not if it is
>> >microsoft).
>> >
>> >You are also making assumptions about the protocol used, but that
>> >is a minor point given the above
>>
>> No. Your modemlog shows that you have added nothing to your modem's
>> Extra Settings. You have also stated that your EC and compression
>> check boxes were greyed out. This proves that your modem is operating
>> with its default settings. These defaults include V.90, V.42, and
>> V.42bis.
>
>No all it proves it that they are blanked out.
A device will operate at its default power-on settings unless
configured otherwise. That is the meaning of the word "default". Now,
as the configuration is performed by DUN, and as the modemlog is a
record of commands issued by DUN, an absence of configuration commands
proves that there was no change to the default settings. But whatever
you do, please don't do *anything* that could possibly prove you are
wrong. Please don't capture a post-call diagnostic report, please
don't post the missing lines of your modemlog, and please don't add
any commands to your Extra Settings that could possibly damage your
fragile ego. And above all, please don't go to Control Panel -> Modems
-> Diagnostics -> More Info in case we find out what modem you really
have.
>> >Do you know mine and the OP's settings?
>>
>> I know enough about your settings to know that they are far from
>> optimal. At the very least you should increase your port rate to
>> 115200bps, for performance reasons.
>
>My modem is 56k I have increased my comm1 port setting to 115200
Irrelevant if you have done it from Device Manager.
>however I dont think it really cares what you set it to.
You will double your throughput for compressible files, unless
software compression is enabled. If your modem connects at 48000bps or
better, and if it can maintain this speed, then you should see a
slight improvement in throughput for incompressible files as well.
>>You would also benefit from
>> knowing your actual connect speed, eg 44000bps, rather than having DUN
>> tell you what you already know, ie that you port rate is 57600bps.
>>
>> >I can't find out what mine are at the monent anyhow.
>>
>> I've shown you how, but you appear to be unable and unwilling to
>> follow instructions.
>
>Nobody tell me what to do, not unless you are paying a decent hourly rate.
Someone who is unable to follow simple instructions is unemployable.
>You instructuions failed anyhow.
Tell Richard Gamberg, author of modemsite.com. Most of the
instructions are his, not mine. Maybe he has more patience than I.
>> Follow my links to modemsite.com and learn something about your modem,
>> as I have done.
>
>I dont take orders.
Not yet, but if you ever enter the workforce that's all you'll be fit
for. Would you like fries with that?
half_pint
Well my modem works fine so at least he is not as ignorant as you.
>
> >Secondly there is no ability to set the DTE setting,
>
> Millions of people have achieved this impossible task. With a little
> knowledge and effort you can too.
Well they wasted their time as the values set in windows are ignored,
anyway I told you in an earlier post how to set it the DTE setting as you
were barking up the wrong tree.
LOL you though that was a genuine question!!!! Your are obviously
far denser than I originally thought.
>
> >> This would have limited you to a max throughput of only
> >> 5.76kB/s, which would mean that your COM port is throttling your
> >> modem's performance. At 5.76kB/s and 8.20 bits/byte (according to my
> >> testing), this amounts to only 47232bps. OTOH, a COM port that is
> >> correctly configured for 115200bps would be subject to no such
> >> limitations, even at a theoretical maximum DCE rate of 56000bps. In
> >> any case, there is nothing to prevent a modem from *connecting* at a
> >> DCE rate higher than its DTE rate.
> >>
> >> This post demonstrates why it is silly to limit your port rate to
> >> 57600bps as you have done:
> >
> >Those were are modem settings.
>
> No, as I've explained to you elsewhere, you set up the COM port, and
> the modem "autobauds" to these settings. So in effect you are
> configuring the modem as a *consequence* of configuring the port. BTW,
> I'm talking about configuring the COM port in the Modem Properties of
> the DUN connectoid, not in Device Manager.
They are clearly marked as modem properties, take it up with Microsoft
>
>
>http://groups.google.com/groups?selm=VKjW9.1855%24zF6.155226%40bgtnsc04-new
Wrong. Not my modem anyway.
>That is the meaning of the word "default".
Wrong.
>Now,
> as the configuration is performed by DUN, and as the modemlog is a
> record of commands issued by DUN, an absence of configuration commands
> proves that there was no change to the default settings.
Wrong.
>But whatever
> you do, please don't do *anything* that could possibly prove you are
> wrong. Please don't capture a post-call diagnostic report, please
> don't post the missing lines of your modemlog, and please don't add
> any commands to your Extra Settings that could possibly damage your
> fragile ego. And above all, please don't go to Control Panel -> Modems
> -> Diagnostics -> More Info in case we find out what modem you really
> have.
That won't tell me which modem I have all it will tell me is which one I
selected from the settings, my modem is not even listed there anyway.
I could probably choose any old modem and it would work.
>
> >> >Do you know mine and the OP's settings?
> >>
> >> I know enough about your settings to know that they are far from
> >> optimal. At the very least you should increase your port rate to
> >> 115200bps, for performance reasons.
> >
> >My modem is 56k I have increased my comm1 port setting to 115200
>
> Irrelevant if you have done it from Device Manager.
>
> >however I dont think it really cares what you set it to.
>
> You will double your throughput for compressible files, unless
> software compression is enabled. If your modem connects at 48000bps or
> better, and if it can maintain this speed, then you should see a
> slight improvement in throughput for incompressible files as well.
Anyone who live in the real world knows that no significant ammount of
data is sent uncompressed, it's a non-started
>
> >>You would also benefit from
> >> knowing your actual connect speed, eg 44000bps, rather than having DUN
> >> tell you what you already know, ie that you port rate is 57600bps.
> >>
> >> >I can't find out what mine are at the monent anyhow.
> >>
> >> I've shown you how, but you appear to be unable and unwilling to
> >> follow instructions.
> >
> >Nobody tell me what to do, not unless you are paying a decent hourly
rate.
>
> Someone who is unable to follow simple instructions is unemployable.
Well you may have been employed as a brainless moron in you time but
I am employed because I have a brain of my own, not to carry out
instructions like a brainless moron.
>
> >You instructuions failed anyhow.
>
> Tell Richard Gamberg, author of modemsite.com. Most of the
> instructions are his, not mine. Maybe he has more patience than I.
You tell him you pompous git.
>
> >> Follow my links to modemsite.com and learn something about your modem,
> >> as I have done.
> >
> >I dont take orders.
>
> Not yet, but if you ever enter the workforce that's all you'll be fit
> for. Would you like fries with that?
I doubt an McDonalds would employ an idiot like you.
It would probably take you a week to grill one burger and
even then it would be burnt to a cinder.
half_pint
very useful for isatance.
Using standard modem I get connection speed 115200,
moden baud rate 28000 and connection time 21 seconds
However with standard 56k flex modem I get connection speed 115200,
moden baud rate 56000 and connection time 19 seconds.
In the former case I still get a full baud rate (not the
28000, as I can see I am obviously faster). But I
do get a 2 seconds knocked of my connection thime which is nice.