Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment 427 Kbps max theoretical, but ILO at low power ... (Score 1) 75

> most likely the result of the small bandwidth they can work with due to the computer not being booted up or something - because for example the "BIOS" can only receiver commands at 1kb/s or something

That, or since it's low on power, the data rate is much lower than max. (That's to be expected, over long distances, lower power signals need to be slower.)

The transceiver is capable of up to 427 Kbps or 720 Kbps, depending on the source you read.
http://stereo.gsfc.nasa.gov/im...
http://stereo.gsfc.nasa.gov/sp...

As you said, it's entirely possible that the main computer can do that data rate, but the IPMI/DRAC/ILO is far slower, or the lack of available power dictates a slow rate.

Comment Yeah, I interpreted it wrong (Score 1) 75

You're right. I interpreted that "20 seconds" as meaning 20 seconds delay. That would indicate a distance about 12-13 times as far as the moon. As you mentioned, the craft is actually roughly on the opposite side of earth's orbit, near where the earth will be in 5-6 months. That's a much further distance, about 16 minutes at the speed of light.

Comment Need to turn it on to find out what's going on (Score 1) 75

TFA quoted one of the NASA engineers "If we turn on the computer, which is the only way we can get insight into the current state of the spacecraft ... what got us into this mess in the first place could turn back on again."

It seems that in order to really know what commands to send, they first need to query some data from the computer. So something like:

Query the most interesting parameter. 20 seconds to rx the reply. (1:40 remaining)
Decide what to query at next. 10 seconds to think and decide. (1:30 remaining).
Decide on a fix and get it sent off, 1 minute. (30 seconds remaining).
Commands take 20 seconds to reach the spacecraft (10 seconds remaining).
Craft executes the instructions, changing its orientation or whatever is required.
Unpucker.

Comment Do you want to capitalize Nazi or not(si)? (Score 1) 346

> EE nazi here. ... grammar Nazis may now commence in attacking the previous sentence

Is that nazi or Nazi? Please decide. :)

> P.S. Fair game ... as well as this one.

Style guides differ on whether PS should be followed by a colon, if it it should be an en-dash.

Here's one even worse - I lied about the DAC voltage level too. :)

Comment Isn't the aux already analog? Also, levels vs DAC (Score 3, Interesting) 346

> The internal DAC on the prius seems like it works well for CDs and BT, but not on it's auxillary inputs. Thoughts?

  The AUX as in the 3.5mm jack that connects to your (analog) headphone jack? THIS headphone jack?:

> It doesn't seem to have that great of a headphone DAC as it sounds mediocre on everything I plug it into.

If you're plugging from a regular headphone jack, the DAC in the car shouldn't be involved - it is already analog.

As for the "bad DAC", trying turning the volume down considerably on the source and compensating by turning it up on the amp. Any modern DAC should have distortion below the threshold humans can detect in music. HOWEVER, the tiny amp for the headphones or the input it is plugged into could very well be overdriven. Turning down the volume on the source may very well fix your problem.

Here's what happens, when things are right and when they're wrong. When levels are right:
DAC sends 0.14 volts to headphone amp.
Volume is set at 5, so:
Headphone amp multiplies by 5 and sends 0.7V to car input.
(Car input sees near maximum loudness, line-level car input maxes out at 0.77 volts).
Car amp multiplies by 20 and sends 14 volts to speakers.

How things go wrong:

DAC sends 0.14 volts to headphone amp.
Volume is set at 10, so:
Headphone amp multiplies by 10 and tries to send 1.4 to car input.
Headphone amp can only manage 1volt, so the tops of the waves get cut off.
Car input gets 1V, but sinces it maxes out at 0.77V, it chops even more off the top of the wave.
Car amp multiplies by 20 and sends 15 volts to speakers, but not as a smooth wave, the tops are chopped of square.
Speakers try to move in smooth motion, not chopped, distorting the sound even more.

Having the level TOO low on the source creates a different problem.
Suppose there is 0.05V of noise in the source and the wire.
Source outputs 0.2V of music.
Car set to amplify by 40 (to compensate for low source level) also amplifies the noise by 40X.
2V of noise goes to speakers, along with 8V of music.

Comment Growing multiple successful tech ventures (Score 1) 129

You've founded multiple successful ventures related to technology. While many entrepreneurs may manage to pay their own bills working out of their garage, to "own their job", you've had success beyond that, more than once. What do you think is the biggest reason your projects have been much more successful than the typical entrepreneurial venture which never grows beyond just a few people?

Comment Might save me a lot of time, except SQL is signed (Score 1) 148

You got me thinking. You're right,

If SQL had a 64-bit unsigned int, I'd use a pair of them. Alas, it doesn't. Postgres has an IP type which works, but my design has to work for SQL server. On the other hand, Microsoft SQL server does have decimal type, numeric. Hmmm ..

On the third hand, the idiot before me decided to store 32-bit integers (ip addresses) as four seperate bytes, in four separate columns (in some tables). That's pretty silly. So when rewriting it to handle IPv6, my first step would be to bring some sanity to the situation by storing each single number in a single column. However if I don't fix it, I can change those four byte columns to four signed 64s (or decimals/numerics) . That would allow a pretty clean conversion, though it preserves the silliness using four columns to store a number.

You're right, though, the IP legitimately is two 64-bit numbers. Unsigned, though. Damn Microsoft.

Comment You can do it the same, or 1:1 nat (not PAT) (Score 1) 148

You can get an IPv6 assignment:
https://www.ripe.net/publicati...

You also use the opportunity to no longer need to work with the next ISP to have your addresses routed by using one-to-one NAT (not the far more commom port address translation, which is yucky). With one-to-one NAT, each machine still has a seperate IP, you can just map the network prefix from FF08:x to BEEF:x or whatever at the router. You can change ISPs instantly in an emergency.

Comment We wish (Score 1) 148

>> And it takes ten times as long compared to using native 64-bit types.
> Depending on operation it should take twice as many calls

Figure out how to manage that and I'll make us both billionaires. Maybe you'd care to demonstrate by showing us how you can two add 4-bit numbers using 2-bit operations.

Are you under the impression that border routers are the only thing that ever sees IP addresses?

Comment 1000% performance penalty on Ivy Bridge (Score 1) 148

64-bit CPUs *can* process 128-bit numbers, or anyway they can run code that emulates it. And it takes ten times as long compared to using native 64-bit types. Your mileage may vary, of course, but that's one benchmark on an Ivy Bridge - a 1000% performance penalty.

Actually try working with 128-bit numbers, IPv6, in common software like SQL Server. There IS no 128-bit unsigned number in SQL Server. You *can* jack around binary types, I have. It's a time-consuming pain in the ass. Speaking of databases, you may have noticed disks are WAY slower than CPUs, RAM, etc. So the bottleneck for performance on well-designed systems is how much data you have to read from disk. If the data is twice as big, you have to read twice as much, and you get half the performance (assuming you didn't add a stupidity bottleneck elsewhere).

64 addresses were provide enough for 2 billion addresses per person. That's already a ridiculously large number.

A compromise position would have ben to *define* IPv6 addresses as 128-bit, and only assign addresses starting with 64 zero bits, for the next couple hundred years or so. That way you'd only need to *process* the lower 64 bits for the next century or so. 200 years from now, we'll have 256-bit CPUs running on 256-bit busses, so it'll be easy to start processing the higher bits at that time, if we need to.

Comment 64 allows 2 billion IPs per person. 2GB limits (Score 1) 148

> Is the Microsoft SQL Server thing the only reason why you think 64-bit would have been better?

SQL server is one example that 64-bit software, on 64-bit computers, natively handles 64-bit numbers, while 128 bit requires gymnastics.

Generally, I think 64 bits would have been more than enough. It would have allowed us to assign 2 billion addresses to each person. :) Not that we'd actually do that, obviously. We would have done perhaps 256 addresses (8 bits) for most end users, while reserving 80%-90% of the address space for future addressing plans. As you said, we using only 190.0.0.0.0.0.0.0/8 (or even 0:0:0/16) would have been plenty for the next 40-200 years.

At the time, we were running into 2GB limits on RAM on Windows disk sizes, and I predicted that the 2TB limit on MBR partitions would be a problem soon. Getting rid of MBR and switching to GPT has in fact been painful. I wanted to go ridiculously big with IPs so we'd never run into a similar problem.

A compromise position would have been to define them as 128 bits, and reserve everything but 0/64 for later use - so all addresses in use would start with 64 zero bits. You'd only have to process the lowest 64 bits, even though the first 64 zeroes technically exist. Then, a hundred years from now, we could announce that we'd start assigning 001:/64 ten years later, so software would need to start paying attention to that additional bit. Of course we'd have 256-bit CPUs by then.

Comment 802.1x. In your use case, buying gets you nothing (Score 1) 87

I don't see that buying a cert gets you anything at all, for authenticating or communicating with your own clients. Why would you trust Versign more than you trust yourself? That's all buying a cert gets you - it's signed by them rather than being signed by you.

Protect your root CA, perhaps by storing it offline, and of course with a passphrase. Ideally for maximum security while maintaining convenience, you can use your root CA only to generate an intermediate cert, then use the intermediate to sign client certs. That way you can have your root locked up in a safe deposit box, since you never use it except once every few years.

I suppose buying does mean you don't have to install your root on new machines when you get them.

  Any way to obtain a cert, for my network only, to authenticate my hosts and clients ... before going out on that damn internet?

That's called IEEE 802.1x. It's commonly used in corporate networks. You can set the router to allow no access until authenticated, or only allow them access to whatever resources are appropriate pre-auth.

Comment There are 5 trillion /56 blocks (Score 5, Interesting) 148

IPv6 has five TRILLION /56 blocks.

There are enough /64 to give every person on earth 2,635,249,153 of them.

128 bits allows for HUGE numbers.

Long ago, when we were developing IPv6, I was part of the group who argued for 128 bit addresses rather than 64 bit. I've decided I was wrong. 64 bits would have been more than enough, and could be processed on 64-bit processors, in standard databases, without hassle. Since my side won the argument, we have 128-bit addresses, which are so big they are a pain in the ass in Microsoft SQL Server and elsewhere.

Slashdot Top Deals

"Ada is PL/I trying to be Smalltalk. -- Codoso diBlini

Working...