Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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.

Non-Tech : CyBerCorp.com -- Ignore unavailable to you. Want to Upgrade?

To: Wes Stevens who wrote (717)	6/4/2000 6:11:00 PM
From: Mark Davis	Read Replies (1) \| Respond to of 1001

I find that the ping times reported match the trace times for the final hop most of the time. As an example, here is a trace to the www.cybercorp.com ip: Pinging 206.242.238.201 with 32 bytes of data: Reply from 206.242.238.201: bytes=32 time=65ms TTL=116 Reply from 206.242.238.201: bytes=32 time=70ms TTL=116 Reply from 206.242.238.201: bytes=32 time=65ms TTL=116 Reply from 206.242.238.201: bytes=32 time=71ms TTL=116 Reply from 206.242.238.201: bytes=32 time=62ms TTL=116 Reply from 206.242.238.201: bytes=32 time=64ms TTL=116 Reply from 206.242.238.201: bytes=32 time=62ms TTL=116 Reply from 206.242.238.201: bytes=32 time=66ms TTL=116 Reply from 206.242.238.201: bytes=32 time=63ms TTL=116 Reply from 206.242.238.201: bytes=32 time=67ms TTL=116 Reply from 206.242.238.201: bytes=32 time=66ms TTL=116 Reply from 206.242.238.201: bytes=32 time=69ms TTL=116 Reply from 206.242.238.201: bytes=32 time=62ms TTL=116 Reply from 206.242.238.201: bytes=32 time=68ms TTL=116 Not bad , right? Now look at this, a trace to the IP address that's reported when you do the reverse VisualTraceRoute. Reply from 206.242.238.99: bytes=32 time=148ms TTL=116 Reply from 206.242.238.99: bytes=32 time=117ms TTL=116 Request timed out. Reply from 206.242.238.99: bytes=32 time=152ms TTL=116 Reply from 206.242.238.99: bytes=32 time=67ms TTL=116 Reply from 206.242.238.99: bytes=32 time=70ms TTL=116 Reply from 206.242.238.99: bytes=32 time=138ms TTL=116 Reply from 206.242.238.99: bytes=32 time=155ms TTL=116 Reply from 206.242.238.99: bytes=32 time=125ms TTL=116 Reply from 206.242.238.99: bytes=32 time=133ms TTL=116 Reply from 206.242.238.99: bytes=32 time=125ms TTL=116 Reply from 206.242.238.99: bytes=32 time=163ms TTL=116 Request timed out. Reply from 206.242.238.99: bytes=32 time=65ms TTL=116 Reply from 206.242.238.99: bytes=32 time=171ms TTL=116 Reply from 206.242.238.99: bytes=32 time=74ms TTL=116 Reply from 206.242.238.99: bytes=32 time=68ms TTL=116 Reply from 206.242.238.99: bytes=32 time=166ms TTL=116 Reply from 206.242.238.99: bytes=32 time=108ms TTL=116 Reply from 206.242.238.99: bytes=32 time=118ms TTL=116 Reply from 206.242.238.99: bytes=32 time=176ms TTL=116 Much longer pings, timeouts, and an examination of the traceroutes shows that after leaving hop 7 in NY, Alternet sends the packet on a DIFFERENT though similar route. I'm no TCP/IP expert, but would have thought that two ip's in the same range would be traveling the same route. Guess not. Can I assume this is some load balancing algorithm? Don't know if this has anything to do with the problems we are having or not. Just an example of how complex and trouble prone all this really is.