If we had gone the way of -1, 0, and 1 like some Soviet systems did this would be two "bits"
Look I'm not a computer scientist, I admit this is naive. But for the thought experiment...
We'd be better off with 9-bit bytes
201–210 of 359 posts
Re: We'd be better off with 9-bit bytes
#202Didn't follow how Github not supporting IPv6 is caused by the "wrong" byte size. Wouldn't 36 bit IP adresses have made that a non-topic?
The author seems to assume Github! is a leader. The masses in IT never have followed leading technology. How many Microsoft engineers do you need to change a light bulb? Zero, MS makes darkness an industry standard.
Are Github actions the leading CI technology?
Re: We'd be better off with 9-bit bytes
#203Earlier quoted context omitted.
Author here. Actually I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed. In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transiti…
why not 10 bit bytes and 40 bit addresses and nice 2 based metric based measures :)
If something is painful you aren't doing it often enough, right? So my (completely uninformed) idea would be 27 bit addresses that are only routable on the local LAN and then a second optional 27 bit address to route between LANs on the WAN. The effective 54 bit address space would have been more than large enough, and if you support modularly extending addresses like that then there's no reason not to keep going beyond the initial 2 by eating into the payload.
Being completely uninformed I have no idea how severe the negative consequences of this scheme would be for the efficiency of routing hardware but I assume it would probably be catastrophic for some reason or another.
Re: We'd be better off with 9-bit bytes
#204Earlier quoted context omitted.
Good points! I was going to say I think 12 bits would have been a nice choice, but yeah optimizing for circuits is kind of important.
Brillant, that 36 bits would be three bytes. "DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. " "Compu…
Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits is also likely to be more practical than 16 bits in most cases.
Re: We'd be better off with 9-bit bytes
#205Earlier quoted context omitted.
One of the nice features of 8 bit bytes is being able to break them into two hex nibbles. 9 bits breaks that, though you could do three octal digits instead I suppose. 10 bit bytes would give us 5-bit nibbles. That would be 0-9a-v digits, which seems a bit extreme.
10-bit has sort of been used. The General Instrument CP1600 family of microprocessors used 16-bit words but all of the instruction opcodes only used 10 bits, with the remaining 6 bits reserved for future use. GI made 10-bit ROMs so that you wouldn't waste 37.5% of your ROM space storing those 6 reserved bits for every opcode. Storing your instructions in 10-bit ROM instead of 16-bit ROM meant that if you needed to st…
I grew up down the road from a GI factory, so assumed everyone knew these things ;)
Re: We'd be better off with 9-bit bytes
#206Re: We'd be better off with 9-bit bytes
#207Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
Not really - I worked on a DSP with 9-bit bytes in the 90's (largely because it was focused on MPEG decode for DVDs, new at the time) largely because memory was still very expensive and MPEG2 needed 9-bit frame difference calculations (most people do this as 16-bits these days but back then as I said memory was expensive and you could buy 9-bit parity RAM chips) It had 512 72-bit registers and was very SIMD/VLIW, was…
Mpact 2?
If memory serves, I had a Creative Labs DXR2 that I almost immediately regretted.
PDP-10 could do 9-bit (or 7, or 6) bytes into 36-bit words. It seems like something that would be fun for 1-2 days.
Re: We'd be better off with 9-bit bytes
#208Re: We'd be better off with 9-bit bytes
#209Earlier quoted context omitted.
That's the fault of whoever designed the router, not IPv6.
As a consumer, I don’t care if it’s Santa Claus’s fault. IPv4: works, IPv6: doesn’t. I don’t even need to know what IPv6 means. I just need to know: Turn it off to make things work. As a technologist, growing up involves learning not to blame the consumer. They are not holding it wrong, you just designed it in a dumb way.
And I'm not blaming the consumer.
If you want to come into a topic and say the problem is that IPv6 did too much, you can't fall back on "it doesn't matter who's at fault". Yes it does matter, that's what this thread is about, that and looking at how technological changes would have affected deployment.
Re: We'd be better off with 9-bit bytes
#210Earlier quoted context omitted.
If you "simply" added more bits to IPv4, you'd have a transition every bit (ahaha, ahem, sorry) as complex as the transition to IPv6 anyway, because IPv4+ would be a new protocol in exactly the same way as IPv6. A new DNS response record. Updates to routing protocols. New hardware. New software. And no interoperability between the two without stateful network address translation.
Author here. The point is that with 9-bit bytes we'd have designed IPv4 to have 36-bit addresses from the beginning. There wouldn't have been a transition.
The post I replied to was speculating on IPv4's life being extended by "simply making the numbers bigger" rather than having more bits per byte, but nevertheless... there still would've been a transition, delayed by at most a few years.
Exhaustion was raised for 32-bit IPv4 in the very early 90s, when we had a few million active Internet users. Allocations were very sparsely used and growth in Internet usage was exponential. It didn't take much of an imagination to foresee a problem.
A 36-bit Internet would be little better. By the middle of the 90s we had ~45 million active Internet users, ending our 16x space advantage, even assuming we didn't just squander that with 8x as wasteful Class A allocations and bigger spaces reserved for uses that will never arise.
Today, we have ~70 billion connected devices: 5-6 billion home subscribers each with multiple devices in the home, 7.5 billion smartphones, 20 billion IoT devices, and all growing rapidly.
We'd need NAT. But NAT was a response to exhaustion concerns, as a stop-gap measure to provide time to design and transition to a proper solution. If we didn't have exhaustion concerns, there'd be no NAT. If we did have exhaustion concerns, brought on perhaps by the lack of NAT, we'd still have invented IPv6, because we'd still have been able to forecast that the Internet would rapidly outgrow 36 bits of address space.
edit: disclaimer, I work in this space, but my comments reflect my own opinion and are not necessarily those of my employer.