If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
"John Harper" wrote in message
news:1061403096.349486@sj-nntpcache-3... Huh? MS attempted to build a NT-based router several years ago and gave up. There is no such animal. Of course there is. Windows comes with Internet Connection Sharing, which is basically a software NAT router. Works fine. OTOH a Linksys router will cost $100-200 at your friendly local Fry's (or whatever) and will do everything required. Not with the satellite hookups, since they require a specific USB connection and driver. I think it's silly the satellite data services don't just use Ethernet, but they don't. You can't use a regular hardware router with them. Pete |
#32
|
|||
|
|||
"Joachim Feise" wrote in message
... The beauty of capitalism is that other companies offering similar systems may see that there is a competitive advantage by offering drivers for other platforms And I hope they do. I think it's silly that any Internet connectivity solution is reliant on a specific software platform, which just building it as an Ethernet access point gives you universal connectivity. True, stability of Windows has gone up, but it is still not at par with *nix. If and when Unix supports the same feature set and wide variety of hardware that Windows does, you will see Unix platforms stability having the same problems people see in Windows. Conservatively, half of all crashes on Windows are due to third-party software and have nothing to do with anything Microsoft wrote or published. People love to say the same thing about Macs. However, first of all, those people apparently forget the "good old days" when the Mac didn't have a real memory manager, and rogue applications caused the entire machine to lock up all the time. Also, those people blame Microsoft and laud Apple, while forgetting that the main reason Macs are so stable is that Apple has complete control over all of the hardware and operating system combinations. They simply have a much smaller test matrix to ensure proper operation. There's a reason that there's a correlation between the number of possible software/hardware combinations and the problems with stablility. [...] There should be no reason for a plain software install to require a reboot. You are right. However, that's just not the fact of life with Windows. Windows itself doesn't require a reboot for basic application installs, but third-party publishers continue to write application installs that require a reboot. That's not Microsoft's fault. Beyond that, some installs DO require a reboot. Anything driver-related that affects hardware that is initialized on boot is going to want to reboot the system. Regardless, it's been years (since I moved our last Win9x machine to Windows 2000) since I've had to reboot a machine just to fix a problem. All reboots have been for reasons unrelated to system stability. It is known, btw, that Windows often has problems with laptop hibernation. And in some versions of Windows, it was actually Windows fault. Win98SE was a particular abomination in this respect (though it did get patched soon after release). However, most of the time it's due to inconsistent implementation of the power control in hardware. Regardless, neither of the laptops in our household have any problem with suspend/hibernate/resume. How well does Linux handle suspend/hibernate/resume? I've never tried it, myself. Pete |
#33
|
|||
|
|||
"Ron Natalie" wrote:
There's no such thing as an ACK packet. A TCP packet can have data as well as the ack for data received. I wouldn't say there's "no such thing". The people I work with generally call a packet with the ACK bit set an "ACK". :-). And if you examine the packets flying in and out during a web surfing session, they usually don't contain any data. The latency in the network is going to affect the retransmission timer on the sending end. Delay is delay. It's not constant, but it is cumulative. I'll concede, though, that as long as the acknowledgement timing is not highly variable, the window will stabilize and you'll get your nominal throughput *for that particular HTTP request*. Another click or a redirect and, presto, another delay. It all adds up. Sorry to flog the dead horse... I'll shut up. -Scott |
#34
|
|||
|
|||
"Peter Duniho" writes:
TCP uses sliding windows to allow constant streaming of data to occur as long as the latency in the connection is "reasonable". That is, it will send many packets before needing to receive any acknowledgement even for the first packet. As long as the acknowledgements start coming in time, the latency of the connection will NOT affect throughput AT ALL. A latency of 500ms is MORE than reasonable in this context. Everything you're saying makes sense to me, but you might want to hang around on news:comp.protocols.tcp-ip for awhile. I regularly notice people trying to debug satellite TCP issues there. It's quite possible that it's just a matter of getting all of the settings tweaked everywhere, but it seems to cause a lot of grief. --kyler |
#35
|
|||
|
|||
Newps writes:
Morgans wrote: During solstices, or even within a few days, the elevation to the sun and the satelite is nearly the same. As the sun transits across the sky, for a period of time, your reciever, the satelite, and the sun are all nearly in line. The sun; since it appears directly on the other side of the transmitter, overcomes the transmitter signal with white noise (radiation) Directv is unaffected. I have had my system for 7 years now. Not so much as a hiccup excpet when there is a heavy wet snow. The snow sticks to the feedhorn. Brush it off and the picture is back. I have turned the TV on in a heavy downpour and checked signal strength, no change. Always in the high 80's here. DirecTV and Dishnetwork are indeed affected. The affection lasts just a few minutes twice a year. Check it at the next equinox, you will see. The exact time varies with your location, I'm sure there's a web page somewhere that will calculate the service-out time for your lat/lon. -jav |
#36
|
|||
|
|||
"Peter Duniho" wrote...
"Pete Zaitcev" wrote... This depends on how big the data piece is relative to the starting handshake. Consider that TCP start-up involves so-called 3-way handshake, and that many protocols have a setup phase when client and server exchange messages strictly in simplex, before bulk data transmission can commence. Regardless, that still only affects the initial delay in response. Even if the delay were 10 seconds (which it's almost never going to be), that's in the same ballpark as the delay some servers have just getting around to servicing a client. It's just not a big deal. Ever tried VOIP over satellite? Painful, is a good one word discription, same for remote access applications, network gaming as mentioned is impossible... [...] So, your downlink is virtually rain proof. The bad news is that the same cannot be said about your uplink. Hmmm...okay, I see. I wasn't aware that they didn't provide a high enough power transmitter to deal with weather. Someone who lives in the desert might not experience as much rainfall that occurs in other parts of the USofA or other countries in the beam... Hmmm Las Vegas just got flooded, so better wording might be, "on a regular basis"... Solstices only knock communication off for several minutes a day, when the Sun is directly behind the satellite. It is a well known effect. I used to depend on an old Soviet satellite Raduga-7 for connectivity, and it was true back then. Several minutes? I guess I'd call that insignificant. That's what, 10 minutes of downtime per year? Big deal. I have to deal with that kind of downtime with my wired DSL access. Nearly 10 minutes per day spread over several days, twice a year... Guaranteed to screw up something important that needed to be done, everytime... Satellite data delivery has faults, just making you aware of it... I've been there done that (our lawyers got the money from the class action lawsuit against Hughes) and won't geaux back (2 cards still sits in the deactivated computers since '98, dishes are still pointed at the satellites) to anything with a ping time over 90 ms to the world... I actually endured the loss of the satellite itself once, and the repointing a few times due to bird migration (moving from one satellite to another, as the provider sees fit)... |
#37
|
|||
|
|||
"Joachim Feise" wrote in message
... How well does Linux handle suspend/hibernate/resume? I've never tried it, myself. A couple years back, the first time I put Linux on my laptop, the network driver wouldn't work after a resume. At that time, reinitializing the network driver was required. Nowadays, I don't experience any problems. Both wired and wireless network come back to life just fine. A couple years back, Windows was handling that just fine on my laptop. Nice to hear Linux has caught up... |
#38
|
|||
|
|||
"Morgans" wrote in message ...
"John Galban" wrote in message om... Newps wrote in message .net... Javier Henderson wrote: I overnighted at CRQ on Friday, and used Western Flight for FBO services. I was pleasantly surprised to find out that they offer complimentary WiFi Internet access to their customers. Details are posted right on the counter. Is the range sufficient that, say, the guy in the tower might be able to access the net? You know how to use a Pringle's can, don't you?? http://www.time.com/time/archive/pre...260724,00.html John Galban=====N4BQ (PA28-180) Like I'm going to pay $2.50 to see a story on the net! NOT! What??? I found the link on Google and it didn't ask me to pay anything. It just showed the article. Go figure. Sorry 'bout that. John Galban=====N4BQ (PA28-180) |
#39
|
|||
|
|||
"Kyler Laird" wrote in message
... If you meant "Unless you are playing online computer games, you would never notice the lag while doing things a typical FBO is likely to do" you should have said so. Of course you're right. This is, after all, the Usenet, and there's always someone around willing to broaden your discussion in an attempt to discredit you. Heaven forbib someone make a try at a little brevity, and leave out critical clauses like "(or something like that)", or "(for example)", or another parenthetical elaboration that would prevent the Usenet pundits from distracting from the underlying point once again. Thank you for the reminder. (Then we'd ask why you thought you had to specifically count out online computer games as something FBOs typically use.) Actually, I mentioned online computer games specifically because there are a handful that I could actually see being used in an FBO. Multiplayer flight sims, for example. The other examples of things that latency would cause problems with are farther afield, and in fact are things many people reading my post would not have even heard of. Pete |
#40
|
|||
|
|||
"Peter Duniho" writes:
"Kyler Laird" wrote in message ... If you meant "Unless you are playing online computer games, you would never notice the lag while doing things a typical FBO is likely to do" you should have said so. Of course you're right. This is, after all, the Usenet, and there's always someone around willing to broaden your discussion in an attempt to discredit you. Well, you *were* wrong. Heaven forbib someone make a try at a little brevity, and leave out critical clauses like "(or something like that)", or "(for example)", or another parenthetical elaboration that would prevent the Usenet pundits from distracting from the underlying point once again. If you're going to say things that are wrong, you should know that someone is likely to nail you. I depend on people doing that for me. If you still think you'll never notice the lag, do as I suggested and set up a voice call to me over a consumer satellite IP service. Do it from an FBO if it makes you happy. I'll be *thrilled* if we don't "notice the lag." --kyler |
Thread Tools | |
Display Modes | |
|
|