OK, this question is totally out of idle curiosity. No customers' jobs
depend on it. No actual electronic repair issues are involved.

Like a surprising number of people, I still have dial-up Internet
access. (Yeah, I know, I'm living in the Stone Age.) So I'm quite
familiar with various connections speeds. I also can observe my network
traffic on my firewall's control panel (I use Sygate, a freebie, which
I'm quite happy with).

What I don't understand is why network traffic, at least as reported by
Sygate, is so choppy. On a good day, I get a "fast" connection, meaning
48 kbps, or maybe even (gasp!) 49.2; that's the fastest speed I ever get.

What I see, invariably, is something like a triangular waveform, with a
period of about a second, where the transmission speed varies from
(usually) 4.4 and 5.9 K (I assume this is bytes, not bits, per second,
but whatever). The speeds never change, at least not much. With a faster
connection, it just stays at the higher speed longer, which flattens out
the peaks of the "waveform".

Why is this? I remember hearing that sending packets down a telephone
wire is a "bursty" business; is that part of it?

Why doesn't the connection just stay at one speed? Why does it alternate
between these two speeds?

Of course, this behavior is only when a single download is being done.
If I'm loading a bunch of web pages and reading Usenet, the "waveform"
becomes very chaotic. But it always seems to be alternating between
various speeds.

Not being an expert on such arcane things as packets and such, I can
only guess that this is kind of like quantum physics, were electrons are
only "allowed" to orbit at certain distances from the nucleus. Is there
a set of standard, agreed-upon telecomm speeds? But why not just pick
one speed and stay there?

Maybe next time I'll ask about how I can get a good, fast connection but
not be able to do anything because DNS isn't working ...


NOTE: Please don't ask me to "Google it"! I post this here intentionally
because I know there must be smart people out there who might be able to
shed some light on the subject. Like I said, idle curiosity, and I'm too
lazy to try to sort through the thousands of pages returned by a search,
weed out the commercial sites, the bogus domain-squatters and
web-scrapers, to get to some good "content" ...


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

In article m,
David Nebenzahl wrote:

OK, this question is totally out of idle curiosity. No customers' jobs
depend on it. No actual electronic repair issues are involved.

Like a surprising number of people, I still have dial-up Internet
access. (Yeah, I know, I'm living in the Stone Age.) So I'm quite
familiar with various connections speeds. I also can observe my network
traffic on my firewall's control panel (I use Sygate, a freebie, which
I'm quite happy with).

What I don't understand is why network traffic, at least as reported by
Sygate, is so choppy. On a good day, I get a "fast" connection, meaning
48 kbps, or maybe even (gasp!) 49.2; that's the fastest speed I ever get.

What I see, invariably, is something like a triangular waveform, with a
period of about a second, where the transmission speed varies from
(usually) 4.4 and 5.9 K (I assume this is bytes, not bits, per second,
but whatever). The speeds never change, at least not much. With a faster
connection, it just stays at the higher speed longer, which flattens out
the peaks of the "waveform".

Why is this? I remember hearing that sending packets down a telephone
wire is a "bursty" business; is that part of it?

There are several aspects to the communication process which can cause
this sort of "burstiness".

One is the phone line itself (the modem-to-modem transmission). Modem
connections these days usually use V.42 error correction technology.
The data being sent is broken up into frames or packets (which may
have separation points that have nothing to do with the underlying
TCP/IP packets). The receiving modem will validate a checksum or CRC
on each frame, and if it's bad (e.g. as the result of some line noise,
corrupting a bit in in the frame) the modem will request that its peer
retransmit the entire frame. The data won't be delivered from the
modem to your PC until it has been successfully received (with the
correct CRC) and you'll observe a brief "stutter" in reception
during each such error-correction... often followed by a burst of
rapidly-delivered data, as those frames which were in transit behind
the damaged one are delivered almost instantly.

TCP is also a burst-prone technology. The sending system will
gradually increase the rate at which it transmits packets (and the
number of packets it transmits without waiting for an acknowledgement)
until something goes "sproing" (that is, a packet is lost due to
errors, or discarded because some router in the path decides that its
buffers are full). The loss of a packet causes the receiving system
to send back a "Hunh? Please resent", or to not send back an
acknowledgement... and these will require retransmission of the lost
packet. Net result is that the net transmission speed varies, as a
result of packet loss and network congestion levels.

--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

David Nebenzahl wrote:

What I see, invariably, is something like a triangular waveform, with a
period of about a second, where the transmission speed varies from
(usually) 4.4 and 5.9 K (I assume this is bytes, not bits, per second,
but whatever). The speeds never change, at least not much. With a faster
connection, it just stays at the higher speed longer, which flattens out
the peaks of the "waveform".

There's a million reasons why speed varies.

It could be line noise, where the modem continually re-negotiates for
the best speed it can.

It could be an iffy line connection, where it works "perfectly" at
lower speeds, so the modem re-negotiates for a higher speed where it
(consistently) fails and falls back again.

It's a bit hard to diagnose this type of problem, more so if you have
modem that does not have good diagnostic feedback on the last call.

If it *IS* noise or line limitations, it might help to force your modem
to 14.4, and see how your connection speed goes. You're looking at
consistency rather than raw speed in this case.

If it IS stable, your line might be going through a pair gain, used by
Telstra to double up on a single copper pair, and splitting up when it
gets near your place. It saves copper wire when they have many
subscribers, plenty of nodes at the exchange, but little copper.

If this is the case, you'll see phone calls work well (albeit sometimes
with crosstalk), Fax works well (9600/14.4) and plays merry hell with
modems that go faster than that.

Good luck with convincing them to fix it though. Even if they DO have
copper to spare, it ends up being a significant resource waster for one
guy who's whining about his modem.
Doesn't hurt to whine though, you might get lucky.

Another option is that it has nothing to do with you or your carrier,
but with your ISP. I've seen bodgy speed throttling techniques that
don't work as well as they should. Though that said, they shouldn't be
going through that anyway, as the modems have inherent speed limitations
to keep them happy anyway.
--
I have a speech impediment... my foot.

On 12/31/2010 5:30 PM John Tserkezis spake thus:

David Nebenzahl wrote:

What I see, invariably, is something like a triangular waveform, with a
period of about a second, where the transmission speed varies from
(usually) 4.4 and 5.9 K (I assume this is bytes, not bits, per second,
but whatever). The speeds never change, at least not much. With a faster
connection, it just stays at the higher speed longer, which flattens out
the peaks of the "waveform".

There's a million reasons why speed varies.

It could be line noise, where the modem continually re-negotiates for
the best speed it can.

It could be an iffy line connection, where it works "perfectly" at
lower speeds, so the modem re-negotiates for a higher speed where it
(consistently) fails and falls back again.

It's a bit hard to diagnose this type of problem, more so if you have
modem that does not have good diagnostic feedback on the last call.

If it *IS* noise or line limitations, it might help to force your modem
to 14.4, and see how your connection speed goes. You're looking at
consistency rather than raw speed in this case.

Thanks for your reply. However, I'm not really reporting or trying to
fix a problem here. I think my connection, for the most part, works
fine. (Actually, there is an easy fix for my problem: $$$.)

I'm just trying to understand *why* it works that way (speed constantly
bouncing between two "notches"). It seems like it's *supposed* to work
that way; why?

I was also going to say something about how it might have something to
do with the negotiation process between client and host, the "REQ/ACK"
process or the equivalent. Not knowing the details of TCP and all that,
I can only guess at what this mechanism is.

Details. I want the gory details.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:

Thanks for your reply. However, I'm not really reporting or trying to
fix a problem here. I think my connection, for the most part, works
fine. (Actually, there is an easy fix for my problem: $$$.)

I'm just trying to understand *why* it works that way (speed constantly
bouncing between two "notches"). It seems like it's *supposed* to work
that way; why?

I was also going to say something about how it might have something to
do with the negotiation process between client and host, the "REQ/ACK"
process or the equivalent. Not knowing the details of TCP and all that,
I can only guess at what this mechanism is.

I didn't entertain the packetising of data, because that is faster than
the graph logging anyway, so you shouldn't even see it.

Besides, from what I remember of modem links, it never behaved that way
anyway, by the time the speed graph showed anything of interest, it was
reasonably steady.

What's the timing of your graph anyway? How frequently does it take a
sample?
--
I'm not opinionated, I'm just always right!

Hi David,

On 12/31/2010 5:34 PM, David Nebenzahl wrote:
What I don't understand is why network traffic, at least as reported by
Sygate, is so choppy. On a good day, I get a "fast" connection, meaning
48 kbps, or maybe even (gasp!) 49.2; that's the fastest speed I ever get.

What I see, invariably, is something like a triangular waveform, with a
period of about a second, where the transmission speed varies from
(usually) 4.4 and 5.9 K (I assume this is bytes, not bits, per second,
but whatever). The speeds never change, at least not much. With a faster
connection, it just stays at the higher speed longer, which flattens out
the peaks of the "waveform".

*What* is being reported -- the number of bytes (bits) per second
leaving some "upper level" of network software? Or, the actual
speed that the *modem* is operating at? (I suspect the former
unless your tool knows how to query *your* modem, directly,
for this information).

So, you have some process in the PC that starts and stops
sending bytes to the modem. The modem probably has a buffer
(even if it is a software modem *in* your PC) that it fills
up with bytes "from" your PC... then, empties into the phone
line... lather, rinse, repeat.

The modem typically doesn't signal the PC after *each*
byte has been pushed out onto the phone line -- that
would involve too much overhead on both sides. Instead,
it imposes a certain amount of hysteresis on the "signaling".
So, a 100 byte buffer says "Full" when it receives it's 100th
byte from the PC.... but, doesn't say "not full" until it
has pushed maybe 80 of those bytes out onto the phone line.

I.e., on a very short time scale, it looks (from the PC's
point of view) like the modem is operating VERY FAST
(gee, it gobbled up those 100 bytes in less than a millisecond)
then very slow (gee, it hasn't asked for ANY more data for
dozens of milliseconds).

(No, this isn't your "problem". Rather, just an example of how
things aren't "continuous time systems" when it comes to this
sort of thing).

Modern modems autonegotiate connection speeds -- based on the
capabilities of the two modems talking to each other *and*
the line conditions in effect from moment to moment.

The connection speed is sort of like the "carrier frequency"
(I am grossly misstating things here just to give you an analogy)
of your local radio station. Your receiver has to be "tuned"
to the same frequency as the transmitter for reception to occur.
The two modems do this continuously while communicating.

ON TOP OF that "carrier", you have your actual data rate.
To further push the radio broadcast analogy, that's like
the rate at which the announcer is talking -- someone who
talks slow vs. someone who talks fast.

[again, this is REALLY a bogus analogy]

The system at the other end of the line (and there can be
several of them cascaded, in effect) can throttle the
data flow. E.g., there is something like the output
buffer of *your* modem on the other end acting as an
"input buffer". It fills and empties in non-continuous
ways based on what *it* is talking to.

Etc.

You can also have underlying "infrastructure" that further
distorts these numbers. E.g., the presence of a SLIC96
can limit available bandwidth (though usually to something
a lot less than what you appear to be seeing) simply because
*it* has a limited bandwidth capability that it imposes
on the lines that it services.

Speeds upwards of 33.6Kbps tend to be more sensitive to line
noise, distance from CO, etc.

You could also have a really noisey line and the noise might
come and go "periodically" -- forcing the modem(s) to change
speeds and/or request retransmissions "regularly".

shrug It's really hard to say what you are experiencing without
actually looking at your line. As a starting point, you can see
if you can query your modem for statistics about the last call,
etc. (doing so varies by model, etc.)

Why is this? I remember hearing that sending packets down a telephone
wire is a "bursty" business; is that part of it?

Why doesn't the connection just stay at one speed? Why does it alternate
between these two speeds?

Of course, this behavior is only when a single download is being done.
If I'm loading a bunch of web pages and reading Usenet, the "waveform"
becomes very chaotic. But it always seems to be alternating between
various speeds.

Not being an expert on such arcane things as packets and such, I can
only guess that this is kind of like quantum physics, were electrons are
only "allowed" to orbit at certain distances from the nucleus. Is there
a set of standard, agreed-upon telecomm speeds? But why not just pick
one speed and stay there?

Maybe next time I'll ask about how I can get a good, fast connection but
not be able to do anything because DNS isn't working ...

Hint: make a note of the IP addresses of various "stable" sites.
When your name resolver isn't working, you can use these numeric
IP addresses to verify that the problem is, in fact, with the
name service and not "The Network".

IIRC, there are some public sites that will provide a *manual*
name service that you could use in a pinch (assuming you
keep a record of their NUMERIC IP addresses)

NOTE: Please don't ask me to "Google it"! I post this here intentionally
because I know there must be smart people out there who might be able to
shed some light on the subject. Like I said, idle curiosity, and I'm too
lazy to try to sort through the thousands of pages returned by a search,
weed out the commercial sites, the bogus domain-squatters and
web-scrapers, to get to some good "content" ...

On 12/31/2010 6:53 PM John Tserkezis spake thus:

David Nebenzahl wrote:

Thanks for your reply. However, I'm not really reporting or trying to
fix a problem here. I think my connection, for the most part, works
fine. (Actually, there is an easy fix for my problem: $$$.)

I'm just trying to understand *why* it works that way (speed constantly
bouncing between two "notches"). It seems like it's *supposed* to work
that way; why?

I was also going to say something about how it might have something to
do with the negotiation process between client and host, the "REQ/ACK"
process or the equivalent. Not knowing the details of TCP and all that,
I can only guess at what this mechanism is.

I didn't entertain the packetising of data, because that is faster than
the graph logging anyway, so you shouldn't even see it.

Besides, from what I remember of modem links, it never behaved that way
anyway, by the time the speed graph showed anything of interest, it was
reasonably steady.

What's the timing of your graph anyway? How frequently does it take a
sample?

As I said, period seems to be about a second. The only time I see a
straight line is if I upload something. I think FTP transfers are a lot
more steady as well. Otherwise, the transfer speed (incoming) is
constantly changing.

I could post a snapshot if you like.

Doesn't seem to be anything wrong with the modem, the phone line or the
system. It just likes to behave that way.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:

As I said, period seems to be about a second. The only time I see a
straight line is if I upload something. I think FTP transfers are a lot
more steady as well. Otherwise, the transfer speed (incoming) is
constantly changing.

I could post a snapshot if you like.

Sure, I'd like to see the timing.
--
Never draw fire, it irritates everyone around you

On 12/31/2010 7:24 PM John Tserkezis spake thus:

David Nebenzahl wrote:

As I said, period seems to be about a second. The only time I see a
straight line is if I upload something. I think FTP transfers are a lot
more steady as well. Otherwise, the transfer speed (incoming) is
constantly changing.

I could post a snapshot if you like.

Sure, I'd like to see the timing.

He
http://s786.photobucket.com/albums/y...Linespeeds.gif

Time divisions are ~3 seconds. This transfer (downloading a picture)
bounced between 3.0 and 4.4 K (which I ass-ume means kilobytes?).

On longer transfers the pattern (sawtooth "wave") becomes very regular.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:

He
http://s786.photobucket.com/albums/y...Linespeeds.gif

Time divisions are ~3 seconds. This transfer (downloading a picture)
bounced between 3.0 and 4.4 K (which I ass-ume means kilobytes?).

On longer transfers the pattern (sawtooth "wave") becomes very regular.

OK, you're talking about 9 seconds or so between each drop and rise,
that's not a protocol issue, it's way too long. It might be a
re-negotiation timing, or something your ISP is doing.
--
What does Santa do at a house with no chimney?

On 12/31/2010 8:39 PM John Tserkezis spake thus:

David Nebenzahl wrote:

He
http://s786.photobucket.com/albums/y...Linespeeds.gif

Time divisions are ~3 seconds. This transfer (downloading a picture)
bounced between 3.0 and 4.4 K (which I ass-ume means kilobytes?).

On longer transfers the pattern (sawtooth "wave") becomes very regular.

OK, you're talking about 9 seconds or so between each drop and rise,
that's not a protocol issue, it's way too long. It might be a
re-negotiation timing, or something your ISP is doing.

No. Maybe I wasn't clear: the time between the time divisions (vertical
lines) is about 3 seconds, so it's about a second between each drop
and rise. The display updates about once a second. (3 samples/time div.)


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:

No. Maybe I wasn't clear: the time between the time divisions (vertical
lines) is about 3 seconds, so it's about a second between each drop and
rise. The display updates about once a second. (3 samples/time div.)

That makes even less sense. If you meant 0.3 Seconds per horizontal
division, that would equate to one second (or thereabouts) per each rise
or trough, allowing that I counted about three divisions for each.
So it appears you've left out a decimal point.

For one second, that might be a bit quick for a re-negotiation, but I
still don't buy the protocol packetising that's doing it.

Have you tried using another graphing logger? It *might* be that it
takes a snapshot, rather than a real average over the timing period.
--
I am free of all prejudice. I hate everyone equally.

On 12/31/2010 9:41 PM John Tserkezis spake thus:

David Nebenzahl wrote:

No. Maybe I wasn't clear: the time between the time divisions (vertical
lines) is about 3 seconds, so it's about a second between each drop and
rise. The display updates about once a second. (3 samples/time div.)

That makes even less sense. If you meant 0.3 Seconds per horizontal
division, that would equate to one second (or thereabouts) per each rise
or trough, allowing that I counted about three divisions for each.
So it appears you've left out a decimal point.

No. You're just not getting what I'm trying to describe.

It's really simple. The display updates once a second. Each vertical
division--the space between two vertical green lines--is 3 seconds. So
there are 3 1-second samples between each pair of vertical lines. The
smallest feature in the display (i.e., the resolution) is 1 second. Does
that make sense?

Have you tried using another graphing logger? It *might* be that it
takes a snapshot, rather than a real average over the timing period.

I don't *have* another graphing logger. This is the one that comes with
the firewall.

Here's another snapshot:
http://s786.photobucket.com/albums/y...speed44-59.gif

Notice how regular the pattern is here (in this case, it's bouncing
between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
bobbles here and there). I've seen such a display that was absolutely
perfectly uniform across the entire display on a long download. (This
was downloading a PDF; line connection speed was 49.2, the highest
possible speed with my setup).


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:

It's really simple. The display updates once a second. Each vertical
division--the space between two vertical green lines--is 3 seconds. So
there are 3 1-second samples between each pair of vertical lines. The
smallest feature in the display (i.e., the resolution) is 1 second. Does
that make sense?

You're describing two different timings.

If it's three seconds per horizontal division, and as per the image, I
saw (about) two to three divisions per peak or trough, (not counting the
steady bit on the right, that equates to six to nine seconds per peak or
trough. That's how it's counted.

Here's another snapshot:
http://s786.photobucket.com/albums/y...speed44-59.gif

Notice how regular the pattern is here (in this case, it's bouncing
between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
bobbles here and there). I've seen such a display that was absolutely
perfectly uniform across the entire display on a long download. (This
was downloading a PDF; line connection speed was 49.2, the highest
possible speed with my setup).

You're talking about the little variations? I get wider variations
that that myself. I just did a test here, and I'm getting quite
significant variations over the download. But, I'm on cable, and I
don't have an active landline modem connection to test otherwise.

In any case, now I officially don't know. Sorry for wasting our time. :-)

As far as speculation goes, one could guess that the internet IP
packets might have something to do with that. Everything gets to your
place in packets. If a few packets get there late, they're still
ordered correctly, but just a little late.

There would be significant (depending on your needs) "jitter" in that
on average, you may have quite constant speeds, but from second to
second, not. You basically don't have any control over the intermediate
data handlers from the site you visit to your destination.
It's actually a bad thing when you're using it for live voice/video
communication (Skype etc), because that type of communications *needs* a
constant supply of data, but the buffering works well enough that you
don't notice too much.


In effect, you're insulated from the effects of Real Life (TM).
--
Follow-ups to alt.nobody.really.cares

On 12/31/2010 10:54 PM John Tserkezis spake thus:

David Nebenzahl wrote:

It's really simple. The display updates once a second. Each vertical
division--the space between two vertical green lines--is 3 seconds. So
there are 3 1-second samples between each pair of vertical lines. The
smallest feature in the display (i.e., the resolution) is 1 second. Does
that make sense?

You're describing two different timings.

If it's three seconds per horizontal division, and as per the image, I
saw (about) two to three divisions per peak or trough, (not counting the
steady bit on the right, that equates to six to nine seconds per peak or
trough. That's how it's counted.

Here's another snapshot:
http://s786.photobucket.com/albums/y...speed44-59.gif

Notice how regular the pattern is here (in this case, it's bouncing
between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
bobbles here and there). I've seen such a display that was absolutely
perfectly uniform across the entire display on a long download. (This
was downloading a PDF; line connection speed was 49.2, the highest
possible speed with my setup).

You're talking about the little variations?

Phew. Finally; yes, that's what I'm talking about, the "little"
fluctuations (between ~4K and ~5K in that second snapshot). They
intrigue me because they're ubiquitous (they happen all the time) and
they're sometimes so regular; it seems like a pattern that must have
something to do with the underlying transfer mechanism. If it's indeed
jitter, it's damned regular jitter.

Since at this point we both seem to be going on pure speculation, I'll
just thank you for your participation so far.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
wrote:

On 12/31/2010 10:54 PM John Tserkezis spake thus:

David Nebenzahl wrote:
http://s786.photobucket.com/albums/y...speed44-59.gif

Phew. Finally; yes, that's what I'm talking about, the "little"
fluctuations (between ~4K and ~5K in that second snapshot).

Methinks you're looking at the effects of roundoff error. There are
not enough packets used for the download test, so the graph is
rounding off the result to the nearest convenient significant figure.
A running average, with larger time slices, would yield a much
smoother and more realistic curve.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 1/1/2011 12:11 AM Jeff Liebermann spake thus:

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
wrote:

On 12/31/2010 10:54 PM John Tserkezis spake thus:

David Nebenzahl wrote:

http://s786.photobucket.com/albums/y...speed44-59.gif

Phew. Finally; yes, that's what I'm talking about, the "little"
fluctuations (between ~4K and ~5K in that second snapshot).

Methinks you're looking at the effects of roundoff error. There are
not enough packets used for the download test, so the graph is
rounding off the result to the nearest convenient significant figure.
A running average, with larger time slices, would yield a much
smoother and more realistic curve.

But as I watch the display during a download, I can see the rate *very
regularly* alternating between two definite speeds (like 4.4 and 5.9 K).
As you can see, the pattern is visible, at least according to this
display. Doesn't that tell us something about how the transfer is taking
place? Or is this just a regularly repeating roundoff error?

In fact, I can tell when the transfer rate is faster or slower, based on
the display: it'll bounce between the same two speeds--that never
changes--but the "flats" on the upper part of the line will be longer,
meaning it's spending more time at the faster speed. The difference is
actually noticeable, in the time it takes to render web pages and such.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

On Fri, 31 Dec 2010 16:34:24 -0800, David Nebenzahl wrote:

OK, this question is totally out of idle curiosity. No customers' jobs
depend on it. No actual electronic repair issues are involved.

Like a surprising number of people, I still have dial-up Internet
access. (Yeah, I know, I'm living in the Stone Age.) So I'm quite
familiar with various connections speeds. I also can observe my network
traffic on my firewall's control panel (I use Sygate, a freebie, which
I'm quite happy with).

What I don't understand is why network traffic, at least as reported by
Sygate, is so choppy. On a good day, I get a "fast" connection, meaning
48 kbps, or maybe even (gasp!) 49.2; that's the fastest speed I ever
get.

LOL



--
Live Fast, Die Young and Leave a Pretty Corpse

On Sat, 01 Jan 2011 00:17:13 -0800, David Nebenzahl
wrote:

On 1/1/2011 12:11 AM Jeff Liebermann spake thus:

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
wrote:

On 12/31/2010 10:54 PM John Tserkezis spake thus:

David Nebenzahl wrote:

http://s786.photobucket.com/albums/y...speed44-59.gif

Phew. Finally; yes, that's what I'm talking about, the "little"
fluctuations (between ~4K and ~5K in that second snapshot).

Methinks you're looking at the effects of roundoff error. There are
not enough packets used for the download test, so the graph is
rounding off the result to the nearest convenient significant figure.
A running average, with larger time slices, would yield a much
smoother and more realistic curve.

But as I watch the display during a download, I can see the rate *very
regularly* alternating between two definite speeds (like 4.4 and 5.9 K).

Toss a coin. From the pattern of heads and tails, I can see a very
regular pattern of randomly alternating heads and tails. OK, bad
analogy, but I thought it was cute. It might be doing 5.75Kbits/sec
and alternately rounding off to the nearest convenient value. Most
speed test software these daze is made for DSL or cable modem speeds.
They use fairly short sampling times, because with the higher speeds,
it's a fair assumption that there will be a sufficient number of bytes
downloaded to get a reasonable value. However, the same software at
dialup speeds is going to see far fewer bytes of traffic, and
therefore generate a more granular result.

As you can see, the pattern is visible, at least according to this
display. Doesn't that tell us something about how the transfer is taking
place? Or is this just a regularly repeating roundoff error?

I think this would be a good time for you to disclose how you're
running this test and what hardware, OS, and software you're using. I
don't like guessing (even though I do it quite often).

In fact, I can tell when the transfer rate is faster or slower, based on
the display: it'll bounce between the same two speeds--that never
changes--but the "flats" on the upper part of the line will be longer,
meaning it's spending more time at the faster speed. The difference is
actually noticeable, in the time it takes to render web pages and such.

It really depends on what your mystery application is doing and how
large or long a sample it takes. If the sample is too short, you'll
get roundoff error. Looking at your usenet news header,
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
it appears that you're using an older copy of Windoze, possibly Win98,
and a 3.5 year old out of date copy of Thunderbird. Therefore, I
won't suggest you use the XP performance monitor to get a better
picture.

Incidentally, if you want to do useful performance measuring, with
clues as to what's going on behind the magic curtain, I suggest you
look at IPerf and JPerf.
http://openmaniak.com/iperf.php
http://code.google.com/p/xjperf/
You may have to update your version of Windoze and Java in order for
it to run properly. You'll find a few IPerf servers available on the
internet, but they're usually reserved for specific users in order to
avoid overload.



--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 1/1/2011 4:19 PM Jeff Liebermann spake thus:

On Sat, 01 Jan 2011 00:17:13 -0800, David Nebenzahl
wrote:

As you can see, the pattern is visible, at least according to this
display. Doesn't that tell us something about how the transfer is
taking place? Or is this just a regularly repeating roundoff error?

I think this would be a good time for you to disclose how you're
running this test and what hardware, OS, and software you're using.
I don't like guessing (even though I do it quite often).

OK: Win2K SP 4; computer is (reading from the Windoze "System
Properties" dialog here as I can't remember the exact MB brand): "x86
Family 6 model 8" (Pentium IV???), running at, I believe, 700-something
MHz, 786 MB RAM. Yeah, not enough RAM, not very fast clock speed by
modren standards, but sheesh, should be able to keep up with a lousy 56K
modem even running full blast, dontcha think?

Test application is Firefox, which is recent (not that it should matter,
right?): v3.6.8. The latest line-speed display I uploaded was while
downloading a PDF of a few megabytes.

Anything else you want to know? Can't tell you the model mfgr., except
that it's a cheapie I got at the local computer guy's store. Nothing
else fancy; no VPNs, PC-Anywhere, proxies, etc., etc.

In fact, I can tell when the transfer rate is faster or slower,
based on the display: it'll bounce between the same two
speeds--that never changes--but the "flats" on the upper part of
the line will be longer, meaning it's spending more time at the
faster speed. The difference is actually noticeable, in the time it
takes to render web pages and such.

Incidentally, if you want to do useful performance measuring, with
clues as to what's going on behind the magic curtain, I suggest you
look at IPerf and JPerf.
http://openmaniak.com/iperf.php
http://code.google.com/p/xjperf/
You may have to update your version of Windoze and Java in order for
it to run properly. You'll find a few IPerf servers available on the
internet, but they're usually reserved for specific users in order to
avoid overload.

Thanks, I'll look into those.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

On Sat, 01 Jan 2011 18:13:15 -0800, David Nebenzahl
wrote:

OK: Win2K SP 4; computer is (reading from the Windoze "System
Properties" dialog here as I can't remember the exact MB brand): "x86
Family 6 model 8" (Pentium IV???), running at, I believe, 700-something
MHz, 786 MB RAM. Yeah, not enough RAM,

768MB RAM is good enough for W2K. Of course, more would be better.

Family 6 Model 8 is a Pentium III mobile. 700Mhz sounds about right
but is rather slow. Any of the later PIII (non-M) Tualatin series
processors, that fit the socket, should work to give you a cheap speed
boost. Clock speeds to 1.33GHz.
http://en.wikipedia.org/wiki/List_of_Intel_Pentium_III_microprocessors

Partial list of processors:
Processor name Processor type
Intel Celeron Intel, x86 Family 6 Model 5
Intel Celeron Intel, x86 Family 6 Model 6
Intel Mobile Pentium III Intel, x86 Family 6 Model 8
Intel Pentium II Intel, x86 Family 6 Model 3
Intel Pentium II Intel, x86 Family 6 Model 5
Intel Pentium II Intel, x86 Family 6 Model 6
Intel Pentium III Intel, x86 Family 6 Model 7
Intel Pentium Pro Intel, x86 Family 6 Model 1
This will work on PIII and older motherboards, but will fail with
Core2Duo and other multicore processors:
http://www.intel.com/support/processors/tools/frequencyid/sb/CS-007623.htm

not very fast clock speed by
modren standards, but sheesh, should be able to keep up with a lousy 56K
modem even running full blast, dontcha think?

Sure. It can keep up with the modem, but perhaps not with the tons of
utilities, applications, drivers, and junk that are all running at the
same time. You'll lose a few clock cycles here and there. It won't
have much of an effect on download speed, but it *MIGHT* have an
effect on the consistency of any diagnostics running on top of the
download. If your modem happens to be a "softmodem" where all the
action ocurrs in software, then it will be even more sensitive to
unrelated activity.

Test application is Firefox, which is recent (not that it should matter,
right?): v3.6.8. The latest line-speed display I uploaded was while
downloading a PDF of a few megabytes.

The current version of Firefox is 3.6.13. To the best of my limited
knowledge, it does NOT have a built in download speed feature. You're
probably using a plugin or add-on, which was downloaded and installed.
Look under:
Tools - Add-ons - Extensions
for the name of the mystery performance monitoring application.

Anything else you want to know?

Nope. Just the name of the Firefox add-on. You supplied everything
else.

Can't tell you the model mfgr., except
that it's a cheapie I got at the local computer guy's store. Nothing
else fancy; no VPNs, PC-Anywhere, proxies, etc., etc.

Good point. I should have asked if you had any resident applications
that might interfere with the download, such as network shims, spyware
scanners, net proxy servers, Zone Alarm, or download managers.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 1/1/2011 7:25 PM Jeff Liebermann spake thus:

On Sat, 01 Jan 2011 18:13:15 -0800, David Nebenzahl
wrote:

Anything else you want to know?

Nope. Just the name of the Firefox add-on. You supplied everything
else.

What Firefox add-on? Didn't you read through the thread? The speed
reporting is from my firewall, Sygate Personal Firewall.

I just went to find their website and was dismayed to find out they've
been bought out by Norton (ugh): http://us.norton.com/sygate


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

On 1/1/2011 4:19 PM Jeff Liebermann spake thus:

Incidentally, if you want to do useful performance measuring, with
clues as to what's going on behind the magic curtain, I suggest you
look at IPerf and JPerf.
http://openmaniak.com/iperf.php
http://code.google.com/p/xjperf/

Regarding that: I looked at the first site and am intrigued, but don't
understand something. I see you need a host and client to make this
work, which makes sense, and as you point out you might (or might not)
be able to use someone else's web-based host; but if not, what then? Can
you somehow set up both host and client on your computah and have the
packets make a "round trip"? (Although that would be a problem since I
notice my upload speeds are a lot slower than download.) How would I use
this to test my dial-up connection?

Also, do I want to test using TCP, UDP or both? Which are used when I
talk to my ISP?


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

On Sat, 01 Jan 2011 20:56:14 -0800, David Nebenzahl
wrote:

On 1/1/2011 4:19 PM Jeff Liebermann spake thus:

Incidentally, if you want to do useful performance measuring, with
clues as to what's going on behind the magic curtain, I suggest you
look at IPerf and JPerf.
http://openmaniak.com/iperf.php
http://code.google.com/p/xjperf/

Regarding that: I looked at the first site and am intrigued, but don't
understand something. I see you need a host and client to make this
work, which makes sense, and as you point out you might (or might not)
be able to use someone else's web-based host; but if not, what then?

If you can't find an iperf server, you're stuck. I did some quick
Googling and couldn't find one that's publicly accessible.

I use IPerf and JPerf mostly for local wireless testing. I setup one
machine to act as a server, and test thruput via wireless under
various conditions. For testing a dialup connection, you would need
an IPerf server located at your ISP or somewhere on the internet. I
could set a temporary server here, at my house, but you would be
limited to my 384Kbit/sec DSL outgoing thruput. Probably good enough
for a dialup modem test. If you want to try that, please let me know.

Can
you somehow set up both host and client on your computah and have the
packets make a "round trip"? (Although that would be a problem since I
notice my upload speeds are a lot slower than download.) How would I use
this to test my dial-up connection?

No. It's not possible to use one computer for both a client and
server. Well, actually, I haven't tried it, but I suspect there will
be problems.

Also, do I want to test using TCP, UDP or both? Which are used when I
talk to my ISP?

Do TCP and forget about UDP for now. UDP testing is tricky and
sometimes results in bizarre results. TCP is reliable.



--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sat, 01 Jan 2011 20:50:40 -0800, David Nebenzahl
wrote:

On 1/1/2011 7:25 PM Jeff Liebermann spake thus:

On Sat, 01 Jan 2011 18:13:15 -0800, David Nebenzahl
wrote:

Anything else you want to know?

Nope. Just the name of the Firefox add-on. You supplied everything
else.

What Firefox add-on? Didn't you read through the thread? The speed
reporting is from my firewall, Sygate Personal Firewall.

I just re-read all 10 of your messages in this thead and did not see
Sygate mentioned anywhere. Unless there was an article that didn't
appear on Giganews, I don't believe you mentioned that the graph came
from Sygate. You did mention that your "test application" was
Firefox, which is why I guessed that it was an add-on.

I just went to find their website and was dismayed to find out they've
been bought out by Norton (ugh): http://us.norton.com/sygate

The mediocre shall inherit the earth.

I was going to try and duplicate your setup, but with such an old
program, it's not going to happen. Sorry, but I've gone as far as I
can trying to explain why you're seeing those variations in speed.

Try this speed test:
http://www.ispgeeks.com/wild/modules.php?name=CapacityTest
It's not a nice neat graph as you were expecting, but it does give
repeatable tests from a well connected server. I'll see if I can find
another server that gives repeated data suitable for graphing.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 02 Jan 2011 00:03:46 -0800, Jeff Liebermann
wrote:

I'll see if I can find
another server that gives repeated data suitable for graphing.

This looks like a likely candidate:
http://speedtestpro.net
No clue if it works with W2K.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 1/2/2011 12:03 AM Jeff Liebermann spake thus:

Try this speed test:
http://www.ispgeeks.com/wild/modules.php?name=CapacityTest
It's not a nice neat graph as you were expecting, but it does give
repeatable tests from a well connected server. I'll see if I can find
another server that gives repeated data suitable for graphing.

I did try it. Interesting.

The test ran fine, but I was surprised to see the Java speed indicator
zoom up to ~700 kbps. I figured there was something perhaps bogus about
the speed test, but then I noticed that my Sygate monitor window also
showed speeds I'd never gotten before; the incoming (download) speed
went up to something like 120 K. Remember, my speeds usually bounce
between ~4 and ~6 K here.

So now I'm really confused. Are these transfer rates real? Remember, I'm
on a 56K modem.

Here's what they reported:

Your download capacity of 627 kbps is very low compared to most
broadband connections.*

Your upload capacity of 493 kbps is acceptable.

Your Quality of Service was measured at 30%, which shows that your
connection is unable to produce a constant stream of data.


* Except, of course, that I don't *have* a broadband connection!

Regarding your generous offer to perhaps set up a host for me to use to
check speeds, thanks, but remember this is just idle curiosity on my part.

If I ever have a real problem, maybe I'll take up your offer, and then
I'll really owe you one.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

David Nebenzahl wrote:
The test ran fine, but I was surprised to see the Java speed indicator
zoom up to ~700 kbps. I figured there was something perhaps bogus about
the speed test, but then I noticed that my Sygate monitor window also
showed speeds I'd never gotten before; the incoming (download) speed
went up to something like 120 K. Remember, my speeds usually bounce
between ~4 and ~6 K here.

It's accurate. As someone else mentioned the modems break the data into packets
as it is sending the data down the line. The data in each packet is compressed
before being sent.

If the speed test were to send truely (or close to it) random packets of 1024
random 8 bit patterns, they would travel at less than rated speed down the line
because there is overhead in packetizing the data, adding checksums, etc.

If the speed test sends a simple pattern, constantly repeated, then the modems
will compress it to a very small string and send that string down the line,
recreating at the far end.

So by analyzing packet timestamps, you could see that a 1k packet of data
comes down the phone line to the modem at some enourmous rate of speed, say
100 times what the line actually handles, and by the time the next packet
arrives, there is a long delay.

So it would show up as a very fast line with lots of instability in performance,
which in this case it is.

In a case with a more random spread of data, it would perform more to your
expectations.

If you wish to have a real test of how well your line performs, find a site
that lets you download video files and time downloading one from start to
finish. As far as modem compression algorythms, video data is almost
100% random and that will remove that variable.

I also would check carefully what you are paying for the combination of
telephone usage ISP charges. I understand the US is a telecom company's
regulatory paradise, but in many places in the world, a cheap broadband
connection has been cheaper than a dial up for many years.

Geoff.

--
Geoffrey S. Mendelson N3OWJ/4X1GM
Those who cannot remember the past are condemned to misquote it.

In article ,
David Nebenzahl wrote:

I did try it. Interesting.

The test ran fine, but I was surprised to see the Java speed indicator
zoom up to ~700 kbps. I figured there was something perhaps bogus about
the speed test, but then I noticed that my Sygate monitor window also
showed speeds I'd never gotten before; the incoming (download) speed
went up to something like 120 K. Remember, my speeds usually bounce
between ~4 and ~6 K here.

So now I'm really confused. Are these transfer rates real? Remember, I'm
on a 56K modem.

It may very well depend on what data they're sending in their test.

Most modem connections incorporate V.42bis data compression. The
sending modem compresses the data before transmitting it, and the
receiving modem decompresses after validating the CRCs in the data
frames.

The effectiveness of the data compression will depend on the data
being sent. HTML, other ASCII text, etc. will usually compress fairly
well (2:1 isn't uncommon), test data consisting of just a single byte
(e.g. zeros) repeated over and over will compress *extremely* well,
and pre-compressed binary data (e.g. .zip archives, .png and .jpeg and
..mpg files) usually won't compress at all.

If the upload and download speed test consists of TCP streams full of
zeros or some other constant data, you could be getting extremely high
compression ratios, and thus an artifically-high link throughput number.

--
Dave Platt AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!