Basic questions about telecommunications

[David Nebenzahl]

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.

 

[Dave Platt]

In article <4d1e768e$0$32417$822641b3@news.adtechcomputers.com>,
David Nebenzahl <nobody@but.us.chickens> 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 <dplatt@radagast.org> 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!

 

[John Tserkezis]

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.

 

[David Nebenzahl]

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.

 

[John Tserkezis]

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!

 

[D Yuniskis]

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

 

[David Nebenzahl]

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.

 

[John Tserkezis]

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

 

[David Nebenzahl]

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.

Here:
http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=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.

 

[John Tserkezis]

David Nebenzahl wrote:

Here:
http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=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?

 

[David Nebenzahl]

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

David Nebenzahl wrote:

Here:
http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=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.

 

[John Tserkezis]

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.

 

[David Nebenzahl]

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/yy147/bonezphoto/?action=view&current=Linespeed44-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.

 

[John Tserkezis]

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/yy147/bonezphoto/?action=view&current=Linespeed44-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

 

[David Nebenzahl]

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/yy147/bonezphoto/?action=view&current=Linespeed44-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.

 

[Jeff Liebermann]

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
<nobody@but.us.chickens> wrote:

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

David Nebenzahl wrote:
http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-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 jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

 

[David Nebenzahl]

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

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
nobody@but.us.chickens> wrote:

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

David Nebenzahl wrote:

http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-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.

 

[Meat Plow]

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

 

[Jeff Liebermann]

On Sat, 01 Jan 2011 00:17:13 -0800, David Nebenzahl
<nobody@but.us.chickens> wrote:

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

On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
nobody@but.us.chickens> wrote:

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

David Nebenzahl wrote:

http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-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 jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

 

[David Nebenzahl]

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

On Sat, 01 Jan 2011 00:17:13 -0800, David Nebenzahl
nobody@but.us.chickens> 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.