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.

Gold/Mining/Energy : Daytrading Canadian stocks in Realtime -- Ignore unavailable to you. Want to Upgrade?

To: Benjamin Ng who wrote (5109)	3/29/1999 1:14:00 PM
From: the Chief	Read Replies (2) \| Respond to of 62347

I am going to go on a limb here...to show you guys my superior TA ability!!<ggg> I predict that at 3:06 this afternoon BII will be at $15.55 If it is below $15.55 then it will close on a downtick at $15.20-25, if above $15.55 then it will close on a weak uptick at $15.70 How's that for an astrological/market analysis!!<gggg> Please feel free to predict so that I am not the only fool out on a limb!! the Chief

To: Benjamin Ng who wrote (5109)	3/29/1999 6:51:00 PM
From: Benjamin Ng	Read Replies (2) \| Respond to of 62347

OFF-TOPIC: Traceroute to CSW Revisited Just had a chance to do a traceroute from two Unix servers on very different networks (ie, two different providers). Both are able to hop to CSW no problems, and the intermediary node between reg4-1.bctel.net and m61.canada-stockwatch.com is 207.194.239.161 (seen as * * * Request Timed Out for most users here). I still get packet loss if I tracert www.canada-stockwatch.com from a Windows NT box. Interestingly though, I can tracert directly to 207.194.239.161 fine. (Could be a way the TTL/ICMP hop count is modified along the way if hops beyond 207.194.239.161 are required.) For fellow techno-geeks, here's my output from one server (upstream of me is Telus Advanced Communications): 3 192.168.12.17 (192.168.12.17) 2.994 ms 9.666 ms 4.499 ms 4 REGIONAL2-fe1-0-0.tac.net (205.233.111.3) 4.703 ms 31.639 ms 11.588 ms 5 inetgw1-tac-reg2.bctel.net (204.174.67.214) 38.782 ms 39.43 ms 42.249 ms 6 reg4-1.bctel.net (204.174.67.49) 42.018 ms 40.233 ms 41.905 ms 7 207.194.239.161 (207.194.239.161) 42.87 ms 45.225 ms 47.065 ms 8 m61.canada-stockwatch.com (207.102.62.61) 48.424 ms 64.513 ms 50.621 ms 9 m30.canada-stockwatch.com (207.102.62.30) 56.548 ms 48.405 ms 48.662 ms In this case, the offending node was hop #7 (for most people that posted earlier, it was hop #9 due to more routers along the way). It may be Windows-unfriendly for certain packets. I'm guessing that anybody using something like Netscape in Linux will have excellent access times compared to Windows users. I've seen this before: a bias against Windows TCP/IP (particularly Win NT) by certain routers. The TCP/IP parameters can be painstakenly tweaked to try and fix the problem. I'm not sure if it's a non-standard implementation of TCP or the parameters themselves. Thank Microsoft. I had a similar problem several months ago using Win NT on my ISP. I simply couldn't view specific sites. Using a different OS on the same machine worked, but was impractical. Tweaking the Win NT TCP settings turned out to be a pain (change registry, reboot, reconnect, repeat). I switched ISPs and the problem was solved (different host of servers and routers). Ben