Re: Quick question.
No need. Remove disk. Insert isk to spare. Start spare server. Allow techs to analyze broken server next day. 1 minute. But in reality, 2 CPU servers are redundant to most COPU failures (had a few cases). Anyway, CPU faiolure is not major reason for server failures (and never was). On Sun, Aug 01, 2004 at 09:44:13AM -0700, Michel Py wrote: In other words, I don't really care if the second processor reduces the MTBF from 200k hours to 60k hours, but I do care if the second processor reduces the time to restore service from 24 hours to 20 minutes (7.5 minutes for SNMP to fail the query twice, 1.5 minute for the tech to find out that either it's frozen or there's a BSOD, 6 minutes to have someone go there and reset, 5 minutes to reboot). With the right form factor (nice easy-to-open rackmount unit) it will take just as little time to swap in an on-site cold-spare. That way you get the nice MTBF and the short restore time. Also, if you have multiple similar machines, you drastically reduce your spares inventory. Unsignificant in my experience, and does not balance what Alexei mentioned yesterday: a duallie will keep the system up when a faulty process hogs 100% CPU, because the second one is still available. That also increases availability ratio. These days you can achieve the same using hyper-threading for example, and keep the long MTBF :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Quick question.
Alexei is talking about something else. a duallie will keep the system up when a faulty process hogs 100% CPU, because the second one is still available. That also increases availability ratio. This is a resource problem, not an availibility problem. A spinning application is not going to take down the machine on any modern OS[2] and anyway can be dealt with with resource limits, SMP or not, presuming your OS supports resource limits. In theory, yes. On pracrtice, 2 CPU improve behavior dramatically. 4 CPU makes system too complex (as you wrote beloow). New P-IV with multi threading may be a good selection - behave as 2 CPU system but is not so complicated as SMP. The real problem with SMP is kernel complexity. Drivers that are rock s/is/was/ (5 years ago). Now most kernels are SMP. I agree that SMP kernels are much more complicated, but we _already_ paid this price. In reality, applications are less reliable on 2 CPU systems (if they have some kinds of bugs, which make sense on SMP only), so I agree with you in some cases.
Re: Quick question.
On Tue, 3 Aug 2004, Alexei Roudnev wrote: It is not mad idea - 2 CPU servers are not sugnificantly more expansive as 1CPU (and notice, we count P-IV MMultiThread as 2 CPU) Well, you have to compare like for like, so system with multiple CPUs versus exact system without. No diffference in cost, other than for the CPUs. And if you want reliability, you're not going to be buying your machines from the nearest Lidl (unless your application is engineered to take advantage of dozens of cheap throwaway PCs). but increases system redundancy to the run-away processes. Of course, it is not hardware redundancy, but it REALLY works. Not really.. this is a resource exhaustion problem, and you can not cure this, given buggy apps, by throwing more CPUs at it. Let's say you have some multi-process or multi-threaded application which regularly spawns/forks new processes/threads, but it is buggy and prone to having individual processes/threads spin. So one spins, but you still have plenty of CPU time left cause you have two CPUs. Another spins, and the machine starts to crawl. So you solve this problem by upgrading to a quad-SMP machine. And guess what happens? :) Sure, there are some application bugs you can mask a wee bit with SMP, but it's not much cop, its not a solution, and you need an infinite-SMP machine to guarantee that a bad application can never hog all CPU time. What you really want is a good OS with: - a good scheduler (to prevent spinning tasks from starving other tasks) - ability to set resource limits, ie per-task and/or per-user (if your apps run under dedicated user accounts) limits on cpu time, resident memory, etc.. Both of these will allow you to constrain the impact bad tasks can have on the system, whether your machine is 1, 2, ... or n CPUs. The real solution though is to fix the buggy application. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The life which is unexamined is not worth living. -- Plato
Re: Quick question.
On Tue, 3 Aug 2004, Alexei Roudnev wrote: In theory, yes. On pracrtice, 2 CPU improve behavior dramatically. That is not about reliability. That's to do with software performance. I was purely picking a, admittedly pedantic, nit with the notion that SMP == more reliable. I'm not trying to argue that SMP does not have other benefits (eg performance). 4 CPU makes system too complex (as you wrote beloow). Nah, the big jump in complexity appears to be from no-concurrency to concurrency. After that initial hurdle, 2 to 4 to 8 CPUs isnt as big a deal (making it scale is though). New P-IV with multi threading may be a good selection - behave as 2 CPU system but is not so complicated as SMP. From the OS POV, the complication is the same. And yes, even single-processors are today capable of presenting multiple execution contexts to software, and it seems to be a trend we'll see more and more of. In reality, applications are less reliable on 2 CPU systems (if they have some kinds of bugs, which make sense on SMP only), so I agree with you in some cases. Right.. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Rubber bands have snappy endings!
Re: Quick question.
- Original Message - From: Paul Jakma [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: Michel Py [EMAIL PROTECTED]; Nanog [EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 2:39 AM Subject: Re: Quick question. --- snip --- Not really.. this is a resource exhaustion problem, and you can not cure this, given buggy apps, by throwing more CPUs at it. Let's say you have some multi-process or multi-threaded application which regularly spawns/forks new processes/threads, but it is buggy and prone to having individual processes/threads spin. So one spins, but you still have plenty of CPU time left cause you have two CPUs. Another spins, and the machine starts to crawl. So you solve this problem by upgrading to a quad-SMP machine. And guess what happens? :) the second cpu buys you time - it is unlikely you're going to be able to react in time on a busy single cpu box with a runaway process (it launches into a death sprial almost immediately), but you would usually have 10-15 mins on a dual cpu box at a minimum or maybe infinity if you enforce cpu affinity for apps that tend to misbehave. paul
Re: Quick question.
On Wed, 4 Aug 2004, Paul G wrote: the second cpu buys you time - it is unlikely you're going to be able to react in time on a busy single cpu box with a runaway process (it launches into a death sprial almost immediately), but you would usually have 10-15 mins on a dual cpu box at a minimum or maybe infinity if you enforce cpu affinity for apps that tend to misbehave. Why do you have 10-15 mins? If the application is multi-threaded and has a reasonable workload, there are plenty of types of bugs that will result in one spinning thread after the other, you need far more than just 2 CPUs! Or maybe your application vendor has at least 10minutes between hitting bugs! on it's feature list? ;) Really, what you to need do is (in the face of such buggy apps) is to set per-task CPU time resource limits appropriate to how much cpu-time a task needs and how much you can afford - be it a 1, 2 or n CPU system. paul regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: I came to MIT to get an education for myself and a diploma for my mother.
Re: Quick question.
- Original Message - Cc: [EMAIL PROTECTED]From: Paul Jakma [EMAIL PROTECTED] To: Paul G [EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 3:09 AM Subject: Re: Quick question. On Wed, 4 Aug 2004, Paul G wrote: the second cpu buys you time - it is unlikely you're going to be able to react in time on a busy single cpu box with a runaway process (it launches into a death sprial almost immediately), but you would usually have 10-15 mins on a dual cpu box at a minimum or maybe infinity if you enforce cpu affinity for apps that tend to misbehave. Why do you have 10-15 mins? If the application is multi-threaded and has a reasonable workload, there are plenty of types of bugs that will result in one spinning thread after the other, you need far more than just 2 CPUs! Or maybe your application vendor has at least 10minutes between hitting bugs! on it's feature list? ;) these are observations, pertaining to software products we use a lot - apache, mysql, apache/suexec, various mtas etc. your point is well taken in general, but at least When Done Here(tm), dual cpu helps significantly empirically speaking. Really, what you to need do is (in the face of such buggy apps) is to set per-task CPU time resource limits appropriate to how much cpu-time a task needs and how much you can afford - be it a 1, 2 or n CPU system. agreed. however, this degrades performance in certain situations, is not practical in others and introduces additional complexity (always a bad thing). the tradeoff is significantly in favor of reactive measures (be they automatic or human intervantion), at least in most of our installations. paul
Re: Quick question.
I said - it WORKS. 1 spin - warning - someone opens system and kills a run away process... Never saw 2 spins (because first one was killed before second one). Btw, such systems (2 CPU) are even more stable in case of run away device drivers. I saw: - run away tomcat server - run away CA agent ([EMAIL PROTECTED]) - run away ssh daemon - run away sandmail All regular, at some periods of time. And all processed without any system degradation because of a few CPU's. The same run-aways on 1 CPU systems caused visible degradation. It is all mattter of trade-off - if I must select 1 threaded or 2 threaded P-IV, I'll select 2 threaded; if I must select from $900 1 CPU and $1100 2 CPU server, I select 2 CPU one. - Original Message - From: Paul Jakma [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: Michel Py [EMAIL PROTECTED]; Nanog [EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 11:39 PM Subject: Re: Quick question. On Tue, 3 Aug 2004, Alexei Roudnev wrote: It is not mad idea - 2 CPU servers are not sugnificantly more expansive as 1CPU (and notice, we count P-IV MMultiThread as 2 CPU) Well, you have to compare like for like, so system with multiple CPUs versus exact system without. No diffference in cost, other than for the CPUs. And if you want reliability, you're not going to be buying your machines from the nearest Lidl (unless your application is engineered to take advantage of dozens of cheap throwaway PCs). but increases system redundancy to the run-away processes. Of course, it is not hardware redundancy, but it REALLY works. Not really.. this is a resource exhaustion problem, and you can not cure this, given buggy apps, by throwing more CPUs at it. Let's say you have some multi-process or multi-threaded application which regularly spawns/forks new processes/threads, but it is buggy and prone to having individual processes/threads spin. So one spins, but you still have plenty of CPU time left cause you have two CPUs. Another spins, and the machine starts to crawl. So you solve this problem by upgrading to a quad-SMP machine. And guess what happens? :) Sure, there are some application bugs you can mask a wee bit with SMP, but it's not much cop, its not a solution, and you need an infinite-SMP machine to guarantee that a bad application can never hog all CPU time. What you really want is a good OS with: - a good scheduler (to prevent spinning tasks from starving other tasks) - ability to set resource limits, ie per-task and/or per-user (if your apps run under dedicated user accounts) limits on cpu time, resident memory, etc.. Both of these will allow you to constrain the impact bad tasks can have on the system, whether your machine is 1, 2, ... or n CPUs. The real solution though is to fix the buggy application. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: The life which is unexamined is not worth living. -- Plato
Re: Quick question.
On Wed, Aug 04, 2004, Alexei Roudnev wrote: I said - it WORKS. 1 spin - warning - someone opens system and kills a run away process... Never saw 2 spins (because first one was killed before second one). Btw, such systems (2 CPU) are even more stable in case of run away device drivers. I call crapola. Modern _modern_ systems may have _some_ of the device drivers running on seperate CPUs but they're still running in kernel mode. A runaway device driver means you're toast. Now, a very very busy device, thats a seperate story. Having one CPU handle all of your disk/network IO and the second CPU handle all of your processes may alleviate some of the pain. May. There's more to it than just offloading stuff. If your processes are all _depending_ on IO to occur then you may end up with random crappy starvation situations. This has nothing to do with NANOG. Lets talk about DCEF bugs or something. Adrian -- Adrian ChaddI'm only a fanboy if [EMAIL PROTECTED] I emailed Wesley Crusher.
XO Mail engineers?
It has come to my attention that XO has "done away" with some of concentric's email systems and have replaced them with new "XO SMTP servers" these new XO SMTP servers aren't allowing people who don't have their mail hosted at XO to relay mail through them even though they are XO DSL customers, you guys may want to rethink your policy on this. It is generally the responsibility of the ISP to provide the outgoing mail transport for your connected users. -Drew
Re: XO Mail engineers?
On Wed, 4 Aug 2004, Drew Weaver wrote: It is generally the responsibility of the ISP to provide the outgoing mail transport for your connected users. This BCP seems to be changing. The new BCP which seems to be evolving requires customers to authenticate to their home mail server on the MSA port and send mail that way. This appears to be being driven by SPF/Sender-ID-like mechanisms. -forrest
Re: XO Mail engineers?
At 03:23 PM 8/4/2004, Forrest W. Christian wrote: On Wed, 4 Aug 2004, Drew Weaver wrote: It is generally the responsibility of the ISP to provide the outgoing mail transport for your connected users. This BCP seems to be changing. The new BCP which seems to be evolving requires customers to authenticate to their home mail server on the MSA port and send mail that way. This appears to be being driven by SPF/Sender-ID-like mechanisms. It is also driven by common sense. Using Submission with AUTH permits users to configure their email service once on their laptops, and use it from wherever they roam. Let's face it, the present crop of mail client software does not make it easy to quickly change outgoing servers, but all popular current mail clients support SMTP AUTH, and to at least some degree (i.e. with some coaching of the end user) support Submission port (587). Let's encourage this. It's good for users. It's good for help desks.
low-latency bandwidth for cheap?
This may be the wrong forum to ask this, and if so I apologize, please just point me in the right direction! I'm getting somewhat frustrated with the instability and high latency of residential cable and DSL offerings, but I love the T1 or greater bandwidth they offer. I'd like reasonable bandwidth with low latency without spending hundreds of dollars per month! Anybody know a good source for near-T1 low-latency bandwidth at around $100/month? I'm in the northern VA area btw. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace
Re: low-latency bandwidth for cheap?
On Wed, 04 Aug 2004 17:25:43 EDT, Jeff Wheeler writes: I'm getting somewhat frustrated with the instability and high latency of residential cable and DSL offerings, but I love the T1 or greater bandwidth they offer. I'd like reasonable bandwidth with low latency without spending hundreds of dollars per month! RFC 1925, 7a. cheers, rw -- -- Dawn is nature's way of telling you to go to bed. -- - And to just stay there until the evil yellow --disk is gone again. pgpPz03wz9fMI.pgp Description: PGP signature
Re: XO Mail engineers?
On Aug 4, 2004, at 12:23 PM, Forrest W. Christian wrote:
This BCP seems to be changing. The new BCP which seems to be evolving
requires customers to authenticate to their home mail server on the MSA
port and send mail that way. This appears to be being driven by
SPF/Sender-ID-like mechanisms.
And at some point in the not-so-distant future {net|sys}ops will look
up from their terminals, blink their eyes a few times and realize that
they have just spent the last $x months jumping through a terrible
number of hoops to support this SPF/SRS thing because everyone is
doing it. And they will realize that all that time/effort/money has
still required users to change the way they do things and that
operators had to waste time implementing a half-solution (or less) when
(this may be unspeakable) in a similar amount of time/effort/money a
real (drastic) solution could have been implemented.
I don't think SPF is worthless [1] but it isn't a drop-in solution and
the impact on infrastructure will be significant if it becomes widely
adopted.
I think people will realize that if we're remodeling the boat that much
we should have at least made sure we were fixing something in the
process...
-david
1: SRS may just be a boondoggle, we'll see.
David A. Ulevitch - Founder, EveryDNS.Net
http://david.ulevitch.com -- http://everydns.net
Re: low-latency bandwidth for cheap?
Jeff Wheeler wrote: Anybody know a good source for near-T1 low-latency bandwidth at around $100/month? I'm in the northern VA area btw. Hi Jeff. I don't know where you are in Northern VA, but, Skynet offers wireless access in eastern Loudoun County with coverage in Leesburg, Sterling and Ashburn. http://www.skynetaccess.com/wdsl.html Hope this helps Jeff
SPF again (Re: XO Mail engineers?)
DAU Date: Wed, 4 Aug 2004 14:46:02 -0700 DAU From: David A. Ulevitch DAU I don't think SPF is worthless [1] but it isn't a drop-in DAU solution and the impact on infrastructure will be DAU significant if it becomes widely adopted. When an architecture is maxed out, it's difficult to make significant improvents that are drop-in. DAU I think people will realize that if we're remodeling the DAU boat that much we should have at least made sure we were DAU fixing something in the process... Indeed. Hogging the TXT RR is a bit greedy. Assuming homogenous policy across a domain name is a stretch. Surely someone else noticed KRB5 and its interaction with DNS. Running something DNS-based that requires simple parsing is hardly an earth-shattering change; it smells similar to DNSBLs, yes? Yet it's still somewhat controversial. And then there's LDAP... In a situation where widespread agreement is mandatory, and consensus is better, drastic changes are difficult. If all netop-related technologies required NANOG-L agreement, nothing would ever get done. I'd like to see widespread adoption of authenticated SMTP, with per-user restrictions on sender address. Alas, that's more difficult than, say, SAV. Call me cynical, but I don't see anything like SMTP auth+restrict taking the world by storm in the near future. No, SPF isn't perfect. I'm trying to decide if it's even good. Are the benefits worth the effort? I'm hopeful, but time will tell. Time will tell, but I'm hopeful. At this point, I'm game to give it a shot. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: SPF again (Re: XO Mail engineers?)
On Aug 4, 2004, at 3:23 PM, Edward B. Dreger wrote: DAU I think people will realize that if we're remodeling the DAU boat that much we should have at least made sure we were DAU fixing something in the process... Indeed. [snip] Running something DNS-based that requires simple parsing is hardly an earth-shattering change; it smells similar to DNSBLs, yes? Yet it's still somewhat controversial. SPF's use of TXT records doesn't bother me so much. It's more that people are (blindly) clamoring for it. SpamAssassin is going to start checking SPF records. If I don't choose to implement SPF my DNS servers are still going to get those TXT record requests. I can't opt-out of that. I don't look forward to getting a taste of what the root-server operators see in their valid/invalid lookup ratios. I think there are going to be some negative consequences as more people implement SPF that will only become apparent at a certain scale. -david David A. Ulevitch - Founder, EveryDNS.Net http://david.ulevitch.com -- http://everydns.net
Re: SPF again (Re: XO Mail engineers?)
DAU Date: Wed, 4 Aug 2004 15:46:17 -0700
DAU From: David A. Ulevitch
DAU SPF's use of TXT records doesn't bother me so much. It's
Perhaps some other technology would like to use TXT RRs. If
something hogs an entire RRTYPE at a given scope, it really
should have its own RRTYPE. An acceptable alternative would be
KRB5-style _foo entries. All IMHO.
DAU more that people are (blindly) clamoring for it.
DAU SpamAssassin is going to start checking SPF records.
DAU
DAU If I don't choose to implement SPF my DNS servers are still
I don't choose to get bounces and other headaches from joe jobs.
DAU going to get those TXT record requests. I can't opt-out of
No, although you can return NODATA or a non-SPF TXT RR, giving
you your choice of negative or positive caching.
DAU that. I don't look forward to getting a taste of what the
DAU root-server operators see in their valid/invalid lookup
DAU ratios.
DAU
DAU I think there are going to be some negative consequences as
DAU more people implement SPF that will only become apparent at
DAU a certain scale.
Perhaps. However, the current { ease of performing } + { time to
educate people re } joe jobs doesn't exactly scale well. I'd not
call SPF a cure, but I still think the sickness is worse than the
experimental treatment.
Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Reporting the state of an apparatus to a remote computer patented
Thought this was relevent to nanog readership.. Abstract The state of an apparatus is reported to a remote computer using an embedded device in the apparatus. The embedded device detects the state, generates an electronic mail message that reports the state using a self-describing computer language, and sends the electronic mail message to the remote computer. The remote computer receives the electronic mail message and extracts the state of the embedded device from the message. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=/netahtml/srchnum.htmr=1f=Gl=50s1=6,757,714.WKU.OS=PN/6,757,714RS=PN/6,757,714 Further, Axeda has 11 additional patents pending in the United States and 10 international patents pending covering other aspects of the remote management of intelligent devices. http://www.axeda.com/products/drm-technology/patented-technology.html
Re: Reporting the state of an apparatus to a remote computer patented
On Wed, 4 Aug 2004, Scott Whyte wrote: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=/netahtml/srchnum.htmr=1f=Gl=50s1=6,757,714.WKU.OS=PN/6,757,714RS=PN/6,757,714 Would avoiding use of XML be enough to circumvent this? -Dan
Re: SPF again (Re: XO Mail engineers?)
On Wed, 4 Aug 2004, David A.Ulevitch wrote: SPF's use of TXT records doesn't bother me so much. It's more that people are (blindly) clamoring for it. Maybe you should -- draft-ymbk-dns-choices-00.txt -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Reporting the state of an apparatus to a remote computer patented
so ... mark lottor's your-machine-room-is-melting thermo+modem circa 1990 is what? prior art?
Re: SPF again (Re: XO Mail engineers?)
Edward B. Dreger wrote: DAU Date: Wed, 4 Aug 2004 15:46:17 -0700 DAU From: David A. Ulevitch DAU SPF's use of TXT records doesn't bother me so much. It's Perhaps some other technology would like to use TXT RRs. If something hogs an entire RRTYPE at a given scope, it really should have its own RRTYPE. An acceptable alternative would be KRB5-style _foo entries. All IMHO. Last time I looked, draft-ietf-marid-protocol-00.txt addressed this issue, 2.1.1 DNS Record Type The record type is a textual RR type to be allocated by the IANA for this purpose. However, because there is a large number of domains with these records already deployed as TXT type records, and because there are a number of DNS server and resolver implementations in common use that cannot handle new RR types, the record type can be TXT. Domains SHOULD publish records under both types. If a domain does publish under both types, then they MUST have the same content. Mail receivers SHOULD query for both types of records. If both are returned, then the new RR type MUST be preferred. It is recognized that the current practice (using a TXT type record), is not optimal, but a practical reality due to the state of deployed records and software. The two record type scheme provides a forward path to the better solution of using a RR type reserved for this purpose. For either type, the character content of the record is encoded as US-ASCII. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: XO Mail engineers?
David A.Ulevitch wrote: 1: SRS may just be a boondoggle, we'll see. Considering MARID seems to be sender id first and the rest nowhere .. http://www.internetnews.com/xSP/article.php/3390221 -- suresh ramasubramanian [EMAIL PROTECTED] gpg EDEDEFB9 manager, security and antispam operations, outblaze ltd
Re: low-latency bandwidth for cheap?
On Wed, Aug 04, 2004 at 11:06:31PM -0400, Jeff Wheeler wrote: Thanks. I suppose then I'm looking for good, and half and half of fast and cheap, or if not then simply good and cheap and I'll accept the lesser bandwidth. Unsure if you've used them, but I've been extremely pleased with Speakeasy and their DSL offerings. We used an SDSL line for a remote office and never had a problem with it. Currently have one of their OneLink (dry pair ADSL) lines up, and will probably have another installed soon. Short of that, being in Texas, I can't really help with any fixed wireless tips. Wes -- FreeBSD administrator, tmb.org Hosting [EMAIL PROTECTED]
Re: low-latency bandwidth for cheap?
Assuming your router supports it and assuming you are primarily browsing, not serving requests, you may want to try one of each. A low-end DSL and cable connection. The chances of both being flakey at the same moment are pretty low [in my experience] and your router should be able to detect fairly quickly if something is amiss. Then again, I have seen at least 50% of the instability-with-DSL complaints in the last 1 year be related to a bad OS on a router or just a bad router that flakes periodically. DJ Jeff Wheeler wrote: Thanks. I suppose then I'm looking for good, and half and half of fast and cheap, or if not then simply good and cheap and I'll accept the lesser bandwidth. -- Jeff Wheeler Postmaster, Network Admin US Institute of Peace On Aug 4, 2004, at 5:42 PM, Robert Waldner wrote: On Wed, 04 Aug 2004 17:25:43 EDT, Jeff Wheeler writes: I'm getting somewhat frustrated with the instability and high latency of residential cable and DSL offerings, but I love the T1 or greater bandwidth they offer. I'd like reasonable bandwidth with low latency without spending hundreds of dollars per month! RFC 1925, 7a. cheers, rw -- -- Dawn is nature's way of telling you to go to bed. -- - And to just stay there until the evil yellow --disk is gone again.
Re: Quick question.
Just again. I do not try to explain, I report observations -:). On Wed, Aug 04, 2004, Alexei Roudnev wrote: I said - it WORKS. 1 spin - warning - someone opens system and kills a run away process... Never saw 2 spins (because first one was killed before second one). Btw, such systems (2 CPU) are even more stable in case of run away device drivers. I call crapola. Modern _modern_ systems may have _some_ of the device drivers running on seperate CPUs but they're still running in kernel mode. A runaway device driver means you're toast. Now, a very very busy device, thats a seperate story. Having one CPU handle all of your disk/network IO and the second CPU handle all of your processes may alleviate some of the pain. May. There's more to it than just offloading stuff. If your processes are all _depending_ on IO to occur then you may end up with random crappy starvation situations. This has nothing to do with NANOG. Lets talk about DCEF bugs or something. Adrian -- Adrian Chadd I'm only a fanboy if [EMAIL PROTECTED] I emailed Wesley Crusher.
Re: Quick question.
On Wed, 4 Aug 2004, Alexei Roudnev wrote: I am sorry, but I do not make a theory - I just repors practical results. 2 CPU systems are much more stable than 1 CPU system, in my experience. You are free to find an explanatiion, if you want -:). The theory suggests your experience is unusual, or that you're overemphasising one positive contributor towards system reliability of complexity against the negative impacts of complexity. Again, I'm not arguing that the more complex system (eg SMP) must always be more unreliable, a well-engineered complex system will be more reliable than a simple but badly-engineered system. I know of an SMP PC server that hit at least 4 years uptime (never rebooted while i was in the employ of that company anyway ;) ), however it would have been just as reliable with just one CPU. And for a large sample of those machines, identical other than single and dual CPU, the set of single CPU machines will be statistically more reliable. Further, for a diverse sample of hardware of varying quality, you will see far more problems with SMP systems - primarily due to software (eg drivers with subtle locking bugs). Nor am I arguing that the tradeoff of reliability for better performance is unwise, particularly since in this case (SMP systems), CPU failures tend to be rare (unless secondary due to some other failure, eg cooling). anyway, I'm repeating myself, so i'll stop before susan larts me, and let the list get back to its favoured topic of discussing analogies. ;) regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: You're working under a slight handicap. You happen to be human.
