<quote who="Howard Lowndes"> > > I've been doing some quantified analysis of the performance of a few PSTN > modems, mainly because I have one that I think is doing something odd. > > The modems in question are: > A Global Express connected to a P120/64Mb > B Swann Smart connected to a P120/64Mb > C D-Link connected to a P120/64Mb > D Dynalink (I think) connected to a Celeron 733/128Mb
Were the tests all carried out over the same 'phone line or four different lines? > > The test is to run several bursts of pings and assess the average response > time. The ping command is: > ping -n -c10 -i0.01 -s8 <target> > This is sending a burst of 10 short ping packets in 1 second with no DNS > resolution. > > The source of these pings is a Celeron 850/128Mb connected to an ADSL > link. > > The results for normal icmp (type 17) packets are: > > A 155msec > B 190msec > C 155msec > D 220msec > > I then looked at pinging the same modems but this time with the ping > packets encapsulated in isakmp (type 50) packets. The results are > somewhat startling: > > A 195msec +40msec > B 240msec +50msec > C 205msec +50msec > D 450msec +230msec > > The really odd bit is that modem D is the one attached to the Celeron > 850/128Mb. > > Similar tests for ADSL (Celeron 850/128Mb) to ADSL sites show around > 55msec for the type 17 packets with about 15msec additional for the type > 50 packets for the tunnelling component despite the fact that the targets > vary between P166/48Mb, Celeron 500/128Mb and Celeron 850/256Mb. > > Can anyone explain why there could be such a variation in the differences > between type 17 and type 50 packets where a PSTN modem is involved? > Agreed that packet sizes will be different with type 50 being bigger, but > is it that much material? I may be way of track here, but I imagine the ping time is the time it takes to receive a correct response to the transmitted ping. When the link is first set up the modems negotiate the fastest satisfactory speed for that particular connection. The algorithm used is sometimes unduly optimistic leading to bit errors. The modem then asks for that byte to be repeated and does not emit the data to the computer until it has received it correctly. If the problem is of this nature it can sometimes be alleviated by explicitly instructing the modem not to attempt connecting above a certain speed (say 22kbps). (There is an AT command for this with some modems) Bit errors are not just caused by noisy lines or excessive attenuation but can be caused by strange frequency and phase response. regards, Ken -- SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
