Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: Re:Do people really take this risk seriously? (Score 4, Insightful) 209

by Spazmania (#49752341) Attached to: Asteroid Risk Greatly Overestimated By Almost Everyone

I also disagree with the premise but in the opposite direction.

Risk is the probability of something happening times the damage if it happens.

If Damage = Death of All (functionally infinite), the Probability need only be more than infinitesimal for the Risk to be significant. Is the probability of a mankind-killer asteroid more than infinitesimal? Well, it's happened a couple times before, so while the probability appears quite small it's certainly more than infinitesimal.

Comment: Re:Idiots (Score 1) 220

Even if you dedicated a core and sat in a busy loop polling the NICs for new packets, you'd still have to wait for the receiving NIC to get the whole packet, you'd still have to set up a DMA transfer to ram, you'd still have to look up the address in an O(log n) trie too large to stay in the L3 cache and you'd still have to set up a DMA transfer from ram to the outbound NIC which would still wait for the entire packet before beginning to transmit it.

"Big Iron" routers don't do this. They wait until they have the whole packet. Then the address is looked up in the O(1) TCAM*, a special tri-state static ram that isn't present in your generic x86 machine. Then the packet is transmitted across the backplane to the outgoing interface without ever touching main memory or the the main processor.

Even then the packet tends to get buffered at least twice with a stochastic probability of waiting in the buffer for other traffic to clear. And that's if you're using a high-quality service provider that avoids running links over 80% of capacity.

* TCAM = Ternary Content Addressable Memory. Bits are organized in rows containing an address or subnet. Each bit can have three states: 1, 0 or "don't care." The address to be looked up is injected at the top of the TCAM and compared against all rows in the TCAM during a single clock. The TCAM outputs the position of the first matching row.

Yes, it's a heater.

Comment: Re:Idiots (Score 1) 220

It's not about the number of cores, it's about the expense of the context switches when servicing the interrupt. The x86 architecture doesn't have register banks the way the old Sparc chips did. Every context switch the registers have to be dumped to ram and the new contents loaded from ram. That's an expensive operation.

Comment: Cakewalk (Score 2) 364

by Spazmania (#49737515) Attached to: Ask Slashdot: Best Way To Solve a Unique Networking Issue?

Get a switch which supports VLANs, 1 vlan on each port and the trunk on your laptop. Then run the mfg's software inside virtual machines, each of which has one of the vlans connected to its virtual ethernet, using the mfg's IP address. Now you can run all the updates in parallel.

The better solution is for the mfg to give you software and a configuration that does not suck. But if you're stuck with it, the above will work just fine.

Comment: Re:Idiots (Score 1) 220

They mostly don't forward until the entire packet is received. That can't work unless the sending interface is the same or lower speed and the hardware for it (hardware fast path at high data rates) tends to be brittle.

Linux does not do this. The ethernet cards Linux uses do not do this. They work with complete packets. In the case of OSes on PC architectures, the kernel may not even get an interrupt until the card has multiple packets to deliver.

Comment: Idiots (Score 5, Insightful) 220

Buffering and switching latency is the main source of delay, not signal latency in the copper and fiber. Microwaves would do exactly nothing to improve the switching and buffering latency. If anything they'd make it worse: light in fiber travels much further than line-of-sight microwave before it has to be regenerated with another delay.

Who peer-reviewed this paper? Did they know the first thing about networking?

Comment: Re:A nuclear power plant (and its control room)? (Score 4, Interesting) 401

Nope. It would scram when the rest of the electric grid collapsed a few days in. The plant has to constantly output power. When the grid fails, the plant automatically goes into safe mode to avoid tearing apart the turbines. Diesel generators then start up to run the plant until grid power returns but they'd only last as long as the fuel.

Nothing associated with the public electric grid would last long without humans present.

Comment: license (Score 1) 2

Plan A: Ask for a perpetual non-exclusive license to the copyrights you create where the work is a general-purpose utility not directly related to the products and services the company provides. Tell the boss straight up that you'd like to refine some of those utilities into products on your own time and then sell them. Agree that the company will retain a perpetual non-exclusive license to any products you produce during your employment which made use of the work you built for the company.

Plan B: Request permission to release the utilities into the public domain. Consume and refine the software on your own time, selling the result. The result, with the productization additions unnecessary for your primary work is covered by your copyright. Anyone could but no one will go back to the public domain work and build back up.

"An ounce of prevention is worth a ton of code." -- an anonymous programmer

Working...