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.

Strategies & Market Trends : TA-Quotes Plus -- Ignore unavailable to you. Want to Upgrade?

To: Ron Wilhoit who wrote (8824)	3/3/1999 8:33:00 PM
From: Sean W. Smith	Read Replies (1) \| Respond to of 11149

Ron, great. you can check the delays to both sites using several methods... tip 1. using ping to measure the time it takes to send a packet to a remote host and have it echoed back to you. [d:\util\4nt]ping -? Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] \| [-k host-list]] [-w timeout] destination-list Options: -t Ping the specifed host until interrupted. -a Resolve addresses to hostnames. -n count Number of echo requests to send. -l size Send buffer size. -f Set Don't Fragment flag in packet. -i TTL Time To Live. -v TOS Type Of Service. -r count Record route for count hops. -s count Timestamp for count hops. -j host-list Loose source route along host-list. -k host-list Strict source route along host-list. -w timeout Timeout in milliseconds to wait for each reply. try something like: ping -n 100 -l 1024 www.qp2.com Pinging www.qp2.com [208.240.130.216] with 1024 bytes of data: Reply from 208.240.130.216: bytes=1024 time=80ms TTL=53 Reply from 208.240.130.216: bytes=1024 time=71ms TTL=53 Reply from 208.240.130.216: bytes=1024 time=80ms TTL=53 Reply from 208.240.130.216: bytes=1024 time=70ms TTL=53 You should get a response for each back. If you get no reply packets are being dropped somewhere. This can definetely cause slow connections. the next step is to use trace route to look at the path to your destination.... tracert www.qp2.com You might see something like follows.... 6 40 ms 40 ms 30 ms digex-gw.cisco.com [209.48.178.1] 7 30 ms 40 ms 41 ms rdu2-core1-h2-0-0.atlas.digex.net [209.48.176.5] 8 40 ms 40 ms 40 ms clt1-core2-h1-0.atlas.digex.net [165.117.52.158] 9 40 ms 50 ms 50 ms atl2-core1-s9-0-0.atlas.digex.net [165.117.50.37] 10 60 ms 50 ms 41 ms 209.49.169.250 11 50 ms 40 ms 50 ms int-5500.interland.net [216.25.127.50] 12 40 ms 50 ms 50 ms quotes-plus.com [208.240.130.216] Each line represents one hop that your packet took. It displays the IP address of the router (name is optional) and then from left to right. max time, nom time, min time... Compare the # of both sites. Look for large increases across a path. This is a slow path or one that is congested. Pinging this host may often result in dropped packets. The first hop going across your modem link should be the slowest anywhere from 250-350 ms ping time for normal operation. trace route also has command flags... tracert -? Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name Options: -d Do not resolve addresses to hostnames. -h maximum_hops Maximum number of hops to search for target. -j host-list Loose source route along host-list. -w timeout Wait timeout milliseconds for each reply. BTW: If anyones wondering why help is '-?' in stead of '/?' as is the DOS standard. these utilities originated on unix and '-' is the default option flag. I guess MS didn't think them worth fixing... :) trying to explain all the uses of the flags and various debug techniques is beyond the scope of this thread. unfortunately I have not found a good online introductory to the subject I can recommend. Most books on MS NT server include some minimal introduction to TCPIP. Sean