ICANN does not control IP allocation at all. IP blocks are allocated by IANA to regional internet registries (ARIN for the Americas, RIPE for Europe and APNIC for Asia to name a few). The regional registries then allocate smaller blocks to organizations in their area.
Routing is different still. No registry guarantees the IP blocks they allocate will be globally routable. Most network providers have their own criteria for determining which networks they will accept routes for.
So, as you can see, ICANN has no part in the allocation or routing of IP addresses.
I and and some friends have had the same problems described by you and others.
Jumpdomain is not a registrar and is simply a reseller for OpenSRS (older domains) and eNom (newer domains). This is good since it means you can end run around them to get your domains transferred.
There have been three problems I've had transferring domains:
1) The admin email address is setup to be an auto@domains.jumpdomain.com (or something similar) which doesn't end up being delivered to the actual admin of the domain. This causes all of the automated transfer emails to not get delivered. You can update this information through OpenSRS at www.adminchange.com. I haven't needed to do this with eNom, but I'm guessing they have a similar process.
2) Domain is locked. This is done specifically to prevent the transfer of the domain and is usually a good thing, but in this case, it's preventing you from using your domain. The Jumpdomain admin interface worked for a few domains, but others I had to contact OpenSRS or eNom directly.
3) No way to access the EPP code needed for EPP registries (like.org and.us). I had to contact eNom directly and after explaining it was for Jumpdomain, they immediately sent the codes out to me.
I highly suggest doing all of this before your domain expires, since you'll need to rewew your domain before you can do any transfers (you might be able to get away with a reseller to reseller transfer with OpenSRS if it's expired, but I don't remember for sure).
It's as much crap as other technologies like IEEE 1394 (Firewire). Greg is concerned with the patent licensing requirements for Infiniband, which is a valid concern, but is no different than the requirements for other technologies that have support under Linux.
In particular, Infiniband requires licensing under RAND terms, similar to that of IEEE 1394.
Re:Stupid question
on
Hack Your Ride
·
· Score: 2, Informative
You have to hold down one of the buttons for about 5 seconds before it recognizes the command. It also only recognizes the command when the engine is not running (atleast I think they changed that now).
I have one of the APR chips for my Audi and use it regularly.
In my case, I have 4 different programs for my ECU. Holding down one of the buttons on my cruise control stalk for 5 seconds, the check engine light starts flashing (yes, poor choice of lights, but it's one of the few the ECU has direct control over) once per second, then after another 5 seconds it flashes twice per second and so on up to 4 times a second. You release the button when the light is flashing the number of times a second that corresponds with the program you want to use.
You could actually do this while the car was running too, but it was very much discouraged (imagine going from full boost on the race program, to nothing on the valet program instantly). I think the latest versions lock out the functionality when the engine is running.
So, to answer your question, normal crise control functionality is not affected.
PostgreSQL comes into play here at the registry. In this case Afilias. They are the authoritative source for all registrations in the.org domain (or will be soon, I'm not sure the exact date). You may recognize them as the registry for.info as well.
All of the DNS infrastructure will be run by UltraDNS and they run Oracle. You may recognize them as the DNS infrastructure provider for.info.
I'm assuming that.org will work the same as.info (since it's the same registry and same DNS server infrastructure) and if so, all changes are incremental and near realtime.
Disclaimer: I used to work at UltraDNS until a couple of months ago when I was laid off.
The service provides a couple of advantages:
Better latency. They use an anycast routing network which guarantees that a query to their DNS servers will be received and answered by the closest server based on the network topology. Even though there is only 2 published IP's for nameservers. There are some 16 servers scattered around the globe to answer on those IP's.
Near real time database updates. They use an Oracle advanced replication network to get updates out to the other servers in near real time.
Proprietary software. The only significant advantage here is that it's not BIND.
All in all, it's about as good as DNS will get. Do you need it for your personal domain? Hardly. Do you need it for a popular domain like slashdot.org? Probably not.
It works best for really large and really popular zones, like TLDs.
However, it's still going to be better (albeit not as significantly) for your personal domain too.
Anyway, bandwidth isn't really the issue with DNS. It's latency and availability.
The problem with your example is that chances are, your DNS server in LA will be getting queries for Europe, which isn't all that ideal. Once again, is it that important? Not really.
There's 3 main host controllers for USB: OHCI (1.1), UHCI (1.1) and EHCI (2.0). There are some other HC's, but they are solely for embedded systems and rare.
ALL three of those are Interrupt (IRQ) driven. ALL three of those have a schedule which is INDEPENDENTELY executed.
There is NEVER busy waiting in USB drivers during normal operation (some HC's will require a busy wait on a register to reset it when you first startup the system, big deal).
The vast majority of changes for USB 2.0 were at a level below what the USB device drivers care about. As a result, most USB 2.0 devices will work with the old USB driver developed against USB 1.1 devices.
Take for instance Mass Storage devices. The Linux USB 2.0 support was developed against a USB 2.0 Mass Storage device. 95% of the development was the EHCI host controll driver. 4% was in the core (to support some new USB 2.0 features) and 1% was in the Mass Storage driver.
There are some new features that USB 2.0 introduced, but there aren't many and are well worth the additions.
Linux has had support much longer than the article implies. Here's one post which is significantly before.
In fact, this isn't the first since it mentions the USB 2.0 support that was in the 2.4 -ac kernel. It only mentions a patch for Linus' 2.4 kernel tree.
Actually, it makes us less than a year behind. Why? Because this article is incorrectly assuming that the 2.4.19 final release is the first time anyone sees any Linux USB 2.0 support.
There has been a stable USB 2.0 patch for well over a year, it has been in the 2.5 kernel since it forked and it's been in 2.4 for a while, albeit under the "Experimental" heading or waiting for the final 2.4.19 kernel to be released.
Like you mentioned, the biggest problem with adding support for USB 2.0 was the lack of devices. The vast majority of development was done with one USB 2.0 controller and one USB 2.0 device. Both were prerelease versions with a whole slew of bugs to workaround.
The reason why you see Itanium support being so mature was because of the priorities of Intel, not of the community. Intel (and HP) sunk a significant amount of money into getting Linux ported to Itanium. Why? Because it's a billion times harder than USB 2.0 support and much more fundamental and thusly important to have supported as early as possible.
You're seeing a couple of different things happening here.
The host controller is the host side hardware which supports USB. For USB 1.1 (there was a 1.0 standard, but it's broken and hasn't been used in years) there was OHCI and UHCI.
For USB 2.0, there's EHCI.
You can't run USB 2.0 on an OHCI or EHCI HCD. You can't run USB 1.1 on an EHCI HCD.
So how does backward and forward compatibility work? Simple. Your USB 2.0 card has both 1.1 and 2.0 HCD's on it. Most likely you have a couple of OHCI controllers and a couple of EHCI controllers on it.
That's why Linux saw the 1.1 controllers, because they need to exist to support 1.1 devices plugged into the root hub. Windows will also see the 1.1 controllers for the same reason.
Now, back to my subject. I call bullshit on devices working a hell of a lot faster in Windows. Why? Because the HCD is the bottleneck. If you plug a 1.1 device into your 2.0 card, it'll still be using the 1.1 controller that's on that card. The 1.1 controller is limited to 12Mbps.
The testing I've done (as well as other people) shows that Linux is consistently faster than Windows on almost all devices. For those devices where Linux is slower, it's only slower by an insignificant amount. Hardly "a HELL of a lot".
I won't even begin to explain the ignorance behind your assertion that there is nothing to sync your paln with under Linux.
From a high level software perspective, there wasn't that much to do.
The biggest amount of work was developing the driver for the new EHCI host controller. A new host controller was necessary for the USB wire interface changes to support the faster speeds.
The reason why development took a while for the EHCI controller was because of the lack of USB 2.0 devices. It's hard to test a driver when you have no hardware to test it against.
That being said, the article is VERY misleading. Linux has had USB 2.0 support for well over a year now and before 2.5 was forked. It's just that it was backported for 2.4 now. Even that's misleading since it's been in the 2.4.19pre tree since it was forked months ago.
"Grabs the port"? Do you understand how USB works?
First off, it's a host controlled bus. The bus tells every device when it can speak. I wouldn't put it past a device to broken in this regard, but just speaking randomly won't matter if the host isn't expecting it (babble).
USB is also fully protected with CRC. While not 160 bits of md5, it goes a long way to preventing corruption of data.
If you have a situation where data is corrupted, because of the USB bus, I'd be surprised.
I don't know where you're getting your information, but all 3 common USB host controllers (UHCI, OHCI and EHCI) use bus mastering DMA to transfer the data from the device to main memory.
While I'm not sure I would qualify myself as an "Einstein", I would say that I'm a geek.
While I can agree with some of the themes, I generally view training and education as worthless most times. I'd much rather have a piece of software dropped in front of me and give me 2 days to play with it than go off to some training course somewhere else to have it explained to me like I'm a toddler.
Am I the only one?
Re:USB was designed by Intel to waste cpu power
on
USB 2.0 For Linux
·
· Score: 1
UHCI does scatter gather because of the simplistic processing it does. It splits everything into the endpoint sized chunks (8,16,32 or 64 bytes).
OHCI and EHCI are very similar and can do scatter gather as well, but differently than UHCI.
I really suggest you read some of the specs, because UHCI, OHCI and EHCI all do all of the hard work you mention. All the OS does is the higher level USB protocol stuff, which is simple.
We just tell the HC where the data is and where it should go, it does all of the CRC's, bitstuffing, retries, etc.
USB was designed to be simple and it really is. The work the CPU does is negligble.
All of the problems with USB are either a) device specific (don't adhere to the specs, etc) or b) poor HC design (UHCI can eat a bit of PCI bandwidth and is poorly specified in some cases), but nothing is fundamently wrong with USB or requires complex work.
Do you know why EIDE is still around and popular today? Because it's cheap. EIDE is simpler than SCSI.
Do you know why USB will still stay around? Because implenting USB hardware is much easier and cheaper than Firewire.
I don't think either will die.
Re:USB was designed by Intel to waste cpu power
on
USB 2.0 For Linux
·
· Score: 1
I'm not sure where you got the information from, but USB is actually CPU efficient. All of the hard processing is done by the Host Controllers (UHCI, OHCI and EHCI).
In fact, USB from a CPU perspective is simpler than SCSI, IP and in fact, is roughly as complex as Firewire.
There is an EHCI driver and USB 2.0 core patches available right now for Linux.
The current plan is to merge them into the 2.5 kernel, and perhaps backport into the 2.4 kernel once it is deemed stable.
The problem holding back USB 2.0 under Linux is device availability. We've had a couple of vendors donate some USB 2.0 Host Controllers but only 1 device. There are a couple of devices available for purchase now and they work with the aforementioned patches.
The story on pcworld.com is speculation. We have USB 2.0 support, but it's not finished and it will only be finished when we have devices to test against.
Slashdot Mirror
Having been offered a job at Google with a sub 3.0 GPA (for the short time I was there), I can back up your claim that it's not required.
However, it didn't stop them from holding it over my head during the interviewing process and negotiation.
ICANN does not control IP allocation at all. IP blocks are allocated by IANA to regional internet registries (ARIN for the Americas, RIPE for Europe and APNIC for Asia to name a few). The regional registries then allocate smaller blocks to organizations in their area.
Routing is different still. No registry guarantees the IP blocks they allocate will be globally routable. Most network providers have their own criteria for determining which networks they will accept routes for.
So, as you can see, ICANN has no part in the allocation or routing of IP addresses.
I and and some friends have had the same problems described by you and others.
Jumpdomain is not a registrar and is simply a reseller for OpenSRS (older domains) and eNom (newer domains). This is good since it means you can end run around them to get your domains transferred.
There have been three problems I've had transferring domains:
1) The admin email address is setup to be an auto@domains.jumpdomain.com (or something similar) which doesn't end up being delivered to the actual admin of the domain. This causes all of the automated transfer emails to not get delivered. You can update this information through OpenSRS at www.adminchange.com. I haven't needed to do this with eNom, but I'm guessing they have a similar process.
2) Domain is locked. This is done specifically to prevent the transfer of the domain and is usually a good thing, but in this case, it's preventing you from using your domain. The Jumpdomain admin interface worked for a few domains, but others I had to contact OpenSRS or eNom directly.
3) No way to access the EPP code needed for EPP registries (like .org and .us). I had to contact eNom directly and after explaining it was for Jumpdomain, they immediately sent the codes out to me.
I highly suggest doing all of this before your domain expires, since you'll need to rewew your domain before you can do any transfers (you might be able to get away with a reseller to reseller transfer with OpenSRS if it's expired, but I don't remember for sure).
Good luck!
What's wrong with OpenIB?
It's as much crap as other technologies like IEEE 1394 (Firewire). Greg is concerned with the patent licensing requirements for Infiniband, which is a valid concern, but is no different than the requirements for other technologies that have support under Linux.
In particular, Infiniband requires licensing under RAND terms, similar to that of IEEE 1394.
You have to hold down one of the buttons for about 5 seconds before it recognizes the command. It also only recognizes the command when the engine is not running (atleast I think they changed that now).
I have one of the APR chips for my Audi and use it regularly.
In my case, I have 4 different programs for my ECU. Holding down one of the buttons on my cruise control stalk for 5 seconds, the check engine light starts flashing (yes, poor choice of lights, but it's one of the few the ECU has direct control over) once per second, then after another 5 seconds it flashes twice per second and so on up to 4 times a second. You release the button when the light is flashing the number of times a second that corresponds with the program you want to use.
You could actually do this while the car was running too, but it was very much discouraged (imagine going from full boost on the race program, to nothing on the valet program instantly). I think the latest versions lock out the functionality when the engine is running.
So, to answer your question, normal crise control functionality is not affected.
PostgreSQL comes into play here at the registry. In this case Afilias. They are the authoritative source for all registrations in the .org domain (or will be soon, I'm not sure the exact date). You may recognize them as the registry for .info as well.
All of the DNS infrastructure will be run by UltraDNS and they run Oracle. You may recognize them as the DNS infrastructure provider for .info.
I'm assuming that .org will work the same as .info (since it's the same registry and same DNS server infrastructure) and if so, all changes are incremental and near realtime.
Disclaimer: I used to work at UltraDNS until a couple of months ago when I was laid off.
The service provides a couple of advantages:
Better latency. They use an anycast routing network which guarantees that a query to their DNS servers will be received and answered by the closest server based on the network topology. Even though there is only 2 published IP's for nameservers. There are some 16 servers scattered around the globe to answer on those IP's.
Near real time database updates. They use an Oracle advanced replication network to get updates out to the other servers in near real time.
Proprietary software. The only significant advantage here is that it's not BIND.
All in all, it's about as good as DNS will get. Do you need it for your personal domain? Hardly. Do you need it for a popular domain like slashdot.org? Probably not.
It works best for really large and really popular zones, like TLDs.
However, it's still going to be better (albeit not as significantly) for your personal domain too.
Anyway, bandwidth isn't really the issue with DNS. It's latency and availability.
The problem with your example is that chances are, your DNS server in LA will be getting queries for Europe, which isn't all that ideal. Once again, is it that important? Not really.
But it will work obviously.
You'll find 2 different things called "Interrupts" if you do that.
There are IRQ's (request_interrupt) and USB Interrupt transfers. They are completely different, but you'll see references to both.
There's 3 main host controllers for USB: OHCI (1.1), UHCI (1.1) and EHCI (2.0). There are some other HC's, but they are solely for embedded systems and rare.
ALL three of those are Interrupt (IRQ) driven.
ALL three of those have a schedule which is INDEPENDENTELY executed.
There is NEVER busy waiting in USB drivers during normal operation (some HC's will require a busy wait on a register to reset it when you first startup the system, big deal).
It's amazing how wrong you are.
I have no idea what you're talking about, but USB has no bursting.
The only problem I can see is that USB is a shared bus and bulk transfers (what USB CDROM burners use) aren't guaranteed bandwidth.
You could overload the bus and end up with a coaster.
I burn CD's exclusively with my USB 1.1/2.0 burner and haven't had a coaster yet.
The vast majority of changes for USB 2.0 were at a level below what the USB device drivers care about. As a result, most USB 2.0 devices will work with the old USB driver developed against USB 1.1 devices.
Take for instance Mass Storage devices. The Linux USB 2.0 support was developed against a USB 2.0 Mass Storage device. 95% of the development was the EHCI host controll driver. 4% was in the core (to support some new USB 2.0 features) and 1% was in the Mass Storage driver.
There are some new features that USB 2.0 introduced, but there aren't many and are well worth the additions.
Linux has had support much longer than the article implies. Here's one post which is significantly before.
In fact, this isn't the first since it mentions the USB 2.0 support that was in the 2.4 -ac kernel. It only mentions a patch for Linus' 2.4 kernel tree.
Actually, it makes us less than a year behind. Why? Because this article is incorrectly assuming that the 2.4.19 final release is the first time anyone sees any Linux USB 2.0 support.
There has been a stable USB 2.0 patch for well over a year, it has been in the 2.5 kernel since it forked and it's been in 2.4 for a while, albeit under the "Experimental" heading or waiting for the final 2.4.19 kernel to be released.
Like you mentioned, the biggest problem with adding support for USB 2.0 was the lack of devices. The vast majority of development was done with one USB 2.0 controller and one USB 2.0 device. Both were prerelease versions with a whole slew of bugs to workaround.
The reason why you see Itanium support being so mature was because of the priorities of Intel, not of the community. Intel (and HP) sunk a significant amount of money into getting Linux ported to Itanium. Why? Because it's a billion times harder than USB 2.0 support and much more fundamental and thusly important to have supported as early as possible.
You're seeing a couple of different things happening here.
The host controller is the host side hardware which supports USB. For USB 1.1 (there was a 1.0 standard, but it's broken and hasn't been used in years) there was OHCI and UHCI.
For USB 2.0, there's EHCI.
You can't run USB 2.0 on an OHCI or EHCI HCD. You can't run USB 1.1 on an EHCI HCD.
So how does backward and forward compatibility work? Simple. Your USB 2.0 card has both 1.1 and 2.0 HCD's on it. Most likely you have a couple of OHCI controllers and a couple of EHCI controllers on it.
That's why Linux saw the 1.1 controllers, because they need to exist to support 1.1 devices plugged into the root hub. Windows will also see the 1.1 controllers for the same reason.
Now, back to my subject. I call bullshit on devices working a hell of a lot faster in Windows. Why? Because the HCD is the bottleneck. If you plug a 1.1 device into your 2.0 card, it'll still be using the 1.1 controller that's on that card. The 1.1 controller is limited to 12Mbps.
The testing I've done (as well as other people) shows that Linux is consistently faster than Windows on almost all devices. For those devices where Linux is slower, it's only slower by an insignificant amount. Hardly "a HELL of a lot".
I won't even begin to explain the ignorance behind your assertion that there is nothing to sync your paln with under Linux.
From a high level software perspective, there wasn't that much to do.
The biggest amount of work was developing the driver for the new EHCI host controller. A new host controller was necessary for the USB wire interface changes to support the faster speeds.
The reason why development took a while for the EHCI controller was because of the lack of USB 2.0 devices. It's hard to test a driver when you have no hardware to test it against.
That being said, the article is VERY misleading. Linux has had USB 2.0 support for well over a year now and before 2.5 was forked. It's just that it was backported for 2.4 now. Even that's misleading since it's been in the 2.4.19pre tree since it was forked months ago.
127 devices per USB bus. This thing has atleast 3 busses.
The USB 1.1 bus is 11Mbps (per bus), whereas the USB 2.0 bus is 480Mbps.
"Grabs the port"? Do you understand how USB works?
First off, it's a host controlled bus. The bus tells every device when it can speak. I wouldn't put it past a device to broken in this regard, but just speaking randomly won't matter if the host isn't expecting it (babble).
USB is also fully protected with CRC. While not 160 bits of md5, it goes a long way to preventing corruption of data.
If you have a situation where data is corrupted, because of the USB bus, I'd be surprised.
Those aren't USB to PS/2 convertors. They just allow you to connect a device which has been specifically designed to work over either port.
Those aren't the devices you think they are.
I don't know where you're getting your information, but all 3 common USB host controllers (UHCI, OHCI and EHCI) use bus mastering DMA to transfer the data from the device to main memory.
Go check the USB host controller specs for yourself.
While I'm not sure I would qualify myself as an "Einstein", I would say that I'm a geek.
While I can agree with some of the themes, I generally view training and education as worthless most times. I'd much rather have a piece of software dropped in front of me and give me 2 days to play with it than go off to some training course somewhere else to have it explained to me like I'm a toddler.
Am I the only one?
UHCI does scatter gather because of the simplistic processing it does. It splits everything into the endpoint sized chunks (8,16,32 or 64 bytes).
OHCI and EHCI are very similar and can do scatter gather as well, but differently than UHCI.
I really suggest you read some of the specs, because UHCI, OHCI and EHCI all do all of the hard work you mention. All the OS does is the higher level USB protocol stuff, which is simple.
We just tell the HC where the data is and where it should go, it does all of the CRC's, bitstuffing, retries, etc.
USB was designed to be simple and it really is. The work the CPU does is negligble.
All of the problems with USB are either a) device specific (don't adhere to the specs, etc) or b) poor HC design (UHCI can eat a bit of PCI bandwidth and is poorly specified in some cases), but nothing is fundamently wrong with USB or requires complex work.
Do you know why EIDE is still around and popular today? Because it's cheap. EIDE is simpler than SCSI.
Do you know why USB will still stay around? Because implenting USB hardware is much easier and cheaper than Firewire.
I don't think either will die.
I'm not sure where you got the information from, but USB is actually CPU efficient. All of the hard processing is done by the Host Controllers (UHCI, OHCI and EHCI).
In fact, USB from a CPU perspective is simpler than SCSI, IP and in fact, is roughly as complex as Firewire.
There is an EHCI driver and USB 2.0 core patches available right now for Linux.
The current plan is to merge them into the 2.5 kernel, and perhaps backport into the 2.4 kernel once it is deemed stable.
The problem holding back USB 2.0 under Linux is device availability. We've had a couple of vendors donate some USB 2.0 Host Controllers but only 1 device. There are a couple of devices available for purchase now and they work with the aforementioned patches.
The story on pcworld.com is speculation. We have USB 2.0 support, but it's not finished and it will only be finished when we have devices to test against.