SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
SI - Site Forums : Silicon Investor - Welcome New SI Members! -- Ignore unavailable to you. Want to Upgrade?


To: justaninvestor who wrote (3151)11/2/1998 2:04:00 PM
From: SIer formerly known as Joe B.  Read Replies (1) | Respond to of 32871
 
This might help:

madsci.wustl.edu



To: justaninvestor who wrote (3151)11/2/1998 2:27:00 PM
From: David Lawrence  Read Replies (1) | Respond to of 32871
 
The three numbers are the return time for each of the three packets sent to each hop. Sometimes, not all three will be returned, indicating one or more dropped packets by that router; in that event, an asterisk will be displayed in place of the transit time. If none of the three packets are returned, an asterisk will be shown for that hop in place of the IP address, name and transit times.

600+ millisecond hops are atrocious, as you are painfully aware. A router that is running that slow is bound to be dropping packets as well, leading to very long delays. Eventually, your browser (or other TCP/IP program) will follow protocol when it doesn't get an acknowledgement and resend it's packet, but now you're talking delays measured in seconds, not milliseconds. Annoying, isn't it?



To: justaninvestor who wrote (3151)11/2/1998 6:40:00 PM
From: Cheeky Kid  Read Replies (2) | Respond to of 32871
 
bbruin,

Here is mine:

C:\WINDOWS>tracert si2.go2net.com

Tracing route to si2.go2net.com
over a maximum of 30 hops:

1 9 ms 20 ms 19 ms
2 9 ms 9 ms 7 ms
3 52 ms 26 ms 25 ms
4 39 ms 25 ms 27 ms
5 52 ms 35 ms 44 ms
6 29 ms 32 ms 30 ms
7 44 ms 37 ms 34 ms
8 37 ms 34 ms 38 ms
9 35 ms 34 ms 28 ms
10 38 ms 37 ms 27 ms
11 32 ms 30 ms 37 ms

Trace complete.

Do you have an @HOME service in your area? Fastest download time so far was 107.0 average is around 25.0

And I thought I was getting fast downloads with my 56K X2 modem,
fastest with that was 5.2.



To: justaninvestor who wrote (3151)11/2/1998 8:47:00 PM
From: SI Brad  Read Replies (2) | Respond to of 32871
 
This is a response I got from our ISP regarding your @home slowness. It sound's like @home could be doing more to circumvent the public access points by working directly with Sprint. In any case, it's beyond our control to do anything to improve the situation.

- Brad

===================
Brad,

We recently had a similar issue to this with another customer. The
problem that you describe is similar to the problem that another customer was having. I have enclosed the information that a sprint engineer provided to us. If you have any more questions or concerns please let us know.

Thanks,
Andrew

from sprint:

Subject: trace route to 209.125.179.0/24

There are really 2 issues with this.

First is that the the public peering points, Mae-west and east, are
congested and Sprintlink cannot guarantee through put to peers.

Second is that at some point in Home.net, home.net doesn't send the
return icmp echoes back through Mae-east to Sprintlink. Probably after
it reaches w1-fe0-0-100bt.rdc1.nj.home.net, which is physically
located in New Jersey, this router routes traffic destined for
Sprintlink through Mae-East. A trace route from the 209.125.179.0/24
network will confirm this. You would also see the trace route times
degrade once you left Home.net and transitted over Mae-East and it
would appear that Sprintlink was the culprit for the latency. In
reality, it is the public peering points that are over loaded and
Sprintlink and Home.net networks are clean.
The only real fix for this type of problem is to have private
peering set up between Sprint and Home networks. That is an issue for
the legal departments of both networks.

Thank you,
Orin Reams