Also, if you're looking to reduce jitter, you should definitely check out these fiber optic interconnects, with gold-plated connectors. I noticed a marked increase in presence and staging when I switched to their specially polished connectors.
It friggin sucks to be like this when others are around. I feel fine when its just me, alone. Then I am "normal".
"The really hopeless victims of mental illness are to be found among those who appear to be most normal. [...] Their perfect adjustment to that abnormal society is a measure of their mental sickess. [...] Any culture which, in the interests of efficiency or in the name of some political or religious dogma, seeks to standardize the human individual, commits an outrage against man's biological nature."
-- Aldous Huxley, Brave New World Revisited
Re:Demo: no go on Slackware 8.0
on
Uplink
·
· Score: 2
Bit errors aren't that uncommon. Do a sh int serial[#] on a Cisco router and you'll see a number of errors on that line.
Right - it's detecting the error at the link layer (using HDLC or PPP checksums, I guess), and dropping the packet at that point. The Cisco doesn't forward the packet if it knows it's corrupted.
So a partiy packet recovers lost packets? But are there seq. numbers for the parity packet? How do it know that this parity packet is for what pevious packets?
I don't know the details of any protocols that do this, but yes, there would have to be something like sequence numbers to associate packets with the correct parity information. I haven't read the article yet (shame on me) but it sounds like this protocol is much more sophisticated than the one I've described.
Parity bits are also used in serial data transmission to confirm data inegrity - if the parity bit is wrong, then you can be sure that there's something wrong with the link layer.
In this case, the parity packet is being used to recover *lost* data, not to confirm data integrity. You would still have a per-packet checksum to ensure that each packet is valid.
Bit errors are extremely rare on the Internet. Normally when there is a significant chance of data corruption, say on a wireless or analog modem line, you would have strong error checking in the link layer.
Lost packets, on the other hand, are very common . In fact they're an intended consequence of TCP - you send data as fast as possible until packets are dropped, and then you back off. If you're getting lots of loss, it doesn't mean there's something "broken" with the network, it just means that the link is over-saturated.
Furthermore, UDP for data is highly unreliable, and I wouldn't trust it across WAN's.
You're missing the point of UDP. UDP is just a *tiny* layer on top of IP, which adds a little extra information (basically the port number) so that the OS can deliver a packet to the right application. UDP can not be compared with TCP - it doesn't provide reliability and flow control, and it has absolutely no notion of a stream of data. If desired, these can be provided in the application layer (see UDP, TFTP, NFS, etc. etc.)
TCP is a reliable transport, but it's much, much more than that. First off, the fact that you're using TCP doesn't make the path between sender/receiver any more reliable. Your packets get dropped just the same as if they were UDP or any other protocol over IP. TCP provides reliability by retransmitting lost packets, but you knew that. It also provides flow control and congestion avoidance - this means detecting when the receiving end (and the router queues in between) are ready for more data, and throttling your transmission rate to match that capacity. It also means being "fair" to other streams sharing the same bottleneck(s). It does this by "backing off" the number of packets in flight, i.e. halving the congestion window, to reduce the data rate. These algorithms are a very active field of research - there's a *lot* more to TCP than meets the eye of a socket programmer.
When TCP loses a packet, that packet must be retransmitted. This is expensive because it means another RTT.
Anyhoo...
You can think of FEC for data transmission as being analogous to RAID 5 for storage. By adding one extra bit (the XOR of the rest of the word) you can lose any single bit and still know it's value. It's very simple. If the word is:
0 1 0 1
And I add an extra "parity" bit, where the parity bit is 1 is the number of ones in the rest of the word is odd, zero if it's even:
0 1 0 1 [0]
I can now lose any one bit (including of course the parity bit). Eg if I have only
0 1 X 1 [0]
Then I know the missing bit is a '0', because if it were '1' then the parity bit would be a zero.
Applying this to data transmission, you can see that by sending just one extra packet, you greatly reduce the chance of having to retransmit anything.
EG if I have to send you 10 packets over a link with 10% packet loss, there's a 65% chance that I'll have to retransmit one of those packets. (and a 10% chance that each retransmitted packet will have to be sent again, and so on).
However if I'm using FEC and I send one extra "parity" packet, then I only have to retransmit if TWO OR MORE packets are lost. The chances of losing TWO out of the eleven packets is only 30%, so you can see that for an overhead of 10%, I've reduced the number of retransmits by a factor of more than two! I hope those figures are right. I used this tool to calculate them. Of course there are a lot of knobs you can turn depending on how much overhead you can afford for the parity information, and what degree of packet loss you want to be able to tolerate.
Anyway, you can see that there are lots of possible improvements/alternatives to TCP - it's an old protocol and a lot of research has been done since RFC 793.
When are electronic device manufacturers going to stop making power cords with huge "wall wart" transformers?
The picture of the power supply is out of date. I just got the new ones today, and they are not the clunky wall warts. They're the modern, tiny switching power supplies with an interchangeable two prong cord for US and overseas voltages. I'll post a picture in a day or two.
We used the regulated wall-wart supply for the prototypes, because the switching supplies are more expensive, they have to be custom-ordered in large qty, and they take 8 weeks to get.
Re:Firmware was posted...
on
Review: SliMP3
·
· Score: 2
So why don't you go ahead and release the code with comments? And while you're at the it, the schematicwould be nice... And the contents of the configuration eeprom from the altera part... Gerbers, etc...;-)
Sure - first you just have to convince me that there's enough interest in this low-level stuff that it's worth the risk of someone cranking out illegal clones.
SliMP3 is open, in the sense that you can hack the UI and make it do whatever you want, but it's not free as in free beer. Opening the hardware and device drivers would serve a hobbyist's educational interest, sure, but I don't see that our customers or our business would benefit significantly from it.
I have a home network that this could work with quite nicely?that is, other than the fact that I am going to dust off one of my 10/100 auto-sensing hubs just for this purpose and loose my bragging rights of having a completely switched, 100MB home network!!!
I think you're mistaken. AFAIK, there's no such thing as a 100Mbps *switch* that doesn't support 10Mbps, so SliMP3 would work fine on your network.
Hubs that only support 100Mbps are very hard to come by these days.
Re:Firmware was posted...
on
Review: SliMP3
·
· Score: 2
The firmware was posted (finally) for the PIC16F877 controlling the whole thing. Disassembly shows much of it is regular code, but some appears to be encrypted - ie, not real code.
Heh - I was wondering how long before someone loaded it into MPLAB and disassembled it. The funny thing is, it's all written in assembler, so you're just a few comments away from having the source code.:)
The chunk from 0x0600 to 0x0x07FF that isn't valid instructions is actually string data - two 7-bit ASCII characters in each 14-bit program word, to save ROM space. The PIC16F877 can read it's own program memory, so this is more efficient than using a bunch of RETLW instructions like you had to do with the older PICs.
There's a copy of the data sheet in our CVS repository if you're interested. The 40x2 uses about 450ma @ 5V, IIRC.
can one be plugged into a COM port?
No, it uses an 8 bit parallel interface, the same as standard LCD modules. The interface is pretty simple, I'm sure there are some examples out on the web of how to hook one up to your parallel port.
$250+ for an MP3 player that doesn't have it's own storage with a display that doesn't exactly look as professional as other MP3 players on the market...
Umm... not storing the files on the player is the whole point! The idea is that you can have two or three of these in different rooms of your home, and they can all be controlled idependently, with your music all stored in one place. So the amount of music you can access is not limited by the player, and you don't have to replicate your collection between several hard disks.
The display is vacuum fluorescent, as opposed to LCD. They're much more expensive than LCDs, and much more readable. I had trouble taking a good photo of it though - you really need to see it in person.
I chose to go with the VFD because even though it's expensive, the $30 price difference vs. the LCD is not a huge percentage of our cost right now. Some day, we'll might make a cheaper version with a backlit LCD. Right now it doesn't make much sense cost-wise, and people generally feel that the VFD is worth the $$.
And it's not even availiable yet! I wonder how CmdrTaco got his. A "free" review copy perhaps?
Yep, I sent him a prototype so he could write the review. The product will be available for sale in 1-2 weeks.
That clearly wasn't an argument, it was a statement. I don't think that way of stating the laws of thermodynamics is helpful in understanding them, by any means, but the laws of thermodynamics still hold.
Sorry, I was a little snippy because entropy is one of few concepts in physics that I've ever had trouble accepting.
Anyway, I actually learned something on/. tonight, and by that fact alone I feel as if some law of nature has been violated, so I'm satisfied.:)
So no, you can't extract energy from the room all by itself. You need a temperature difference if you hope to have a net output of energy. Unless of course you know how to build the magic black boxes that lead to a net decrease in the entropy of the universe, in which your Nobel prize and billions await.
Excellent explanation, dragons_flight, thanks.
I will now grudgingly accept the known laws of physics, and find another field in which to seek my Nobel prize.:)
It tells you that it's impossible to transfer energy from heat to any other form with 100% efficiency.
Sigh... as I've already said, I'm not arguing against conservation of energy (at least I hope I'm not doing so inadvertently).
It is possible to locally decrease the entropy of one system, but you are guaranteed to increase the entropy of everything else by at least the difference.
Exactly - *this* is what I want. Extract heat from the room as electricty for use later (or somewhere else). Sure, it's going to end up as heat again at some point.
I don't care if this is only 0.000001% efficient. I just want to know that it's possible.
So, if you want to just randomly generate electricity from a warm room, all you have to do is provide one exit for the warm air from the room, and have it lead to a colder room. You put a turbine in that passage, and you'll be able to convert the linear motion of the warm air moving into the cold room into rotational motion and turn a generator.
Agreed, but is this *necessarily* so inefficient as to be impractical? I.e. is it that it can't work, or have we just not figured out how to do it?
anyway, it still wouldn't answer my question. What I'm confused about is the following:
We can convert electricity directly to heat, without having to "cool something else down" in the process. Why doesn't it work in reverse?
1.You can't win.
2.You can't break even.
3.You have no choice about playing.
That's a weak, if not utterly wrong, argument for entropy. I haven't studied thermodynamics, but entropy is something I've heard of, looked up in the dictionary, dug around for on google, etc, and frankly I have never seen a acceptable explanation of this "basic" law which so many take for granted. Why is it that it's always presented as some magical "incresing order of things"?
Heat *is* energy. We have ways of turning it into other forms of energy, they're just inefficient, and generally require temperatures above boiling.
Nobody is proposing that your laptop could power itself off the heat it generates. However, lots of systems are designed to recover some of their "wasted" energy. Electric cars have regenerative brakes, for example. This doesn't make them perpetual motion machines, it just gets them a little closer.
Will the experts please explain the following: why can't I extract heat from the atmosphere, and turn it into electricity/motion/whatever? We have no problem doing this if there's lots of heat (geothermal power plants), but why can't I have a sort of "reverse air conditioner" that works at room temperate?
It's also kind of stupid that you left your car on the street with only those puny door locks. That's why I stole it.
I think you got the wrong car. I left mine in the street with doors and windows open, the keys in the ignition, and the engine running, with a sign in the window saying "thanks for not stealing me".
Kinda stupid, actually. "Hey, we've left our DNS servers accessible to the public with no access control, but please don't use them unless you're paying us"
Most people configure their DNS servers to allow anyone to do a recursive lookup, because usually there's no point in using someone else's DNS as opposed to running your own or using your ISPs.
If they wanted to prevent the public from using their DNS servers, they would have one set of servers only accessible to their own customers, and another set accessible to the world, but which only served domains they were hosting. It's very easy to do, so it's silly of them to insinuate that we're "stealing" by using name servers which have been deliberately left open.
AT&T @Home service in Cupertino, CA is down. The lights on the modem are on, but changing DNS servers or typing IP addresses into the URL does not work. So it looks like the head-end is up, but nothing's getting routed.
I still feel like my $1K/mo T1 is a rip-off, but hey, at least it's up! Although I've heard rumors that XO (the CLEC providing the circuit to HE.NET) is also having financial troubles.
For example, it is possible to place a video server in the CO and a customer could order a movie and the bandwidth pipe between the video server and the subscriber would be opened up accordingly (say 4Mbps, while standard Internet (i.e. web) traffic would remain as it was (say, 512Kbps).
That's an interesting approach, and I there are definitely some applications for it. However, it's an awfully kludgy workaround to the original problem, i.e. that the cost of transmitting a packet depends on the destination.
I don't want my ISP to decide how much *bandwidth* I can have for a particular destination or service. I'd rather that they let me use whatever bandwidth I wanted, and charged me according to the cost of the next hops I use (or better yet, the full path).
Consider the implications this would have in furthering p2p technology, and driving the Internet to a more efficient structure. Content moves to the edges, performance improves, costs decrease. I'd be able to videoconference 24/7 with another customer on the same ISP for pennies a month, while my cross-country traffic is cheaper because those expensive paths are being used more efficiently. Instead of just selling a bandwidth limited pipe that's only good for web surfing, ISPs would become real communities, their value being the content and customers on their networks.
It'll happen. Our demand for bandwidth is insatiable, and this is the only way that huge pipes will ever be affordable for us and profitable for the ISPs.
Slashdot Mirror
And even if they do analise the code...
Microsost *must* be "analising" their code. It's totaly shit, and they charge "per anum" for the license.
Additionaly, seperate preprocessing circuity is used to reclock the signal to exactly match the expected clock.
Dude, re-clocking your S/PDIF won't help at all if your cabling is the bottleneck. These guys can sell you a cable cooker that should do the trick.
Also, if you're looking to reduce jitter, you should definitely check out these fiber optic interconnects, with gold-plated connectors. I noticed a marked increase in presence and staging when I switched to their specially polished connectors.
Gotta watch out for that jitter.
It friggin sucks to be like this when others are around. I feel fine when its just me, alone. Then I am "normal".
"The really hopeless victims of mental illness are to be found among those who appear to be most normal. [...] Their perfect adjustment to that abnormal society is a measure of their mental sickess. [...] Any culture which, in the interests of efficiency or in the name of some political or religious dogma, seeks to standardize the human individual, commits an outrage against man's biological nature."
-- Aldous Huxley, Brave New World Revisited
ap@kira:~/uplink$ file ./uplink
./uplink: ELF 32-bit LSB executable, Intel 80386, version 1 (Linux), statically
Since the site is down, can anyone tell me if this game is available for PPC, or any non-x86 architectures?
Bit errors aren't that uncommon. Do a sh int serial[#] on a Cisco router and you'll see a number of errors on that line.
Right - it's detecting the error at the link layer (using HDLC or PPP checksums, I guess), and dropping the packet at that point. The Cisco doesn't forward the packet if it knows it's corrupted.
So a partiy packet recovers lost packets? But are there seq. numbers for the parity packet? How do it know that this parity packet is for what pevious packets?
I don't know the details of any protocols that do this, but yes, there would have to be something like sequence numbers to associate packets with the correct parity information. I haven't read the article yet (shame on me) but it sounds like this protocol is much more sophisticated than the one I've described.
But what if the parity packet is lost?
Parity bits are also used in serial data transmission to confirm data inegrity - if the parity bit is wrong, then you can be sure that there's something wrong with the link layer.
In this case, the parity packet is being used to recover *lost* data, not to confirm data integrity. You would still have a per-packet checksum to ensure that each packet is valid.
Bit errors are extremely rare on the Internet. Normally when there is a significant chance of data corruption, say on a wireless or analog modem line, you would have strong error checking in the link layer.
Lost packets, on the other hand, are very common . In fact they're an intended consequence of TCP - you send data as fast as possible until packets are dropped, and then you back off. If you're getting lots of loss, it doesn't mean there's something "broken" with the network, it just means that the link is over-saturated.
(see UDP, TFTP, NFS, etc. etc.)
Er... I meant (see DNS, TFTP, NFS, etc. etc.)
Furthermore, UDP for data is highly unreliable, and I wouldn't trust it across WAN's.
You're missing the point of UDP. UDP is just a *tiny* layer on top of IP, which adds a little extra information (basically the port number) so that the OS can deliver a packet to the right application. UDP can not be compared with TCP - it doesn't provide reliability and flow control, and it has absolutely no notion of a stream of data. If desired, these can be provided in the application layer (see UDP, TFTP, NFS, etc. etc.)
TCP is a reliable transport, but it's much, much more than that. First off, the fact that you're using TCP doesn't make the path between sender/receiver any more reliable. Your packets get dropped just the same as if they were UDP or any other protocol over IP. TCP provides reliability by retransmitting lost packets, but you knew that. It also provides flow control and congestion avoidance - this means detecting when the receiving end (and the router queues in between) are ready for more data, and throttling your transmission rate to match that capacity. It also means being "fair" to other streams sharing the same bottleneck(s). It does this by "backing off" the number of packets in flight, i.e. halving the congestion window, to reduce the data rate. These algorithms are a very active field of research - there's a *lot* more to TCP than meets the eye of a socket programmer.
When TCP loses a packet, that packet must be retransmitted. This is expensive because it means another RTT.
Anyhoo...
You can think of FEC for data transmission as being analogous to RAID 5 for storage. By adding one extra bit (the XOR of the rest of the word) you can lose any single bit and still know it's value. It's very simple. If the word is:
0 1 0 1
And I add an extra "parity" bit, where the parity bit is 1 is the number of ones in the rest of the word is odd, zero if it's even:
0 1 0 1 [0]
I can now lose any one bit (including of course the parity bit). Eg if I have only
0 1 X 1 [0]
Then I know the missing bit is a '0', because if it were '1' then the parity bit would be a zero.
Applying this to data transmission, you can see that by sending just one extra packet, you greatly reduce the chance of having to retransmit anything.
EG if I have to send you 10 packets over a link with 10% packet loss, there's a 65% chance that I'll have to retransmit one of those packets. (and a 10% chance that each retransmitted packet will have to be sent again, and so on).
However if I'm using FEC and I send one extra "parity" packet, then I only have to retransmit if TWO OR MORE packets are lost. The chances of losing TWO out of the eleven packets is only 30%, so you can see that for an overhead of 10%, I've reduced the number of retransmits by a factor of more than two! I hope those figures are right. I used this tool to calculate them. Of course there are a lot of knobs you can turn depending on how much overhead you can afford for the parity information, and what degree of packet loss you want to be able to tolerate.
Anyway, you can see that there are lots of possible improvements/alternatives to TCP - it's an old protocol and a lot of research has been done since RFC 793.
I'd too would prefer they'd be made some dope-smoking hacker instead.
:)
This is no joke:
Our MAC addresses start with 00:04:20
And no, you can't specifically request a "vanity" MAC prefix.
When are electronic device manufacturers going to stop making power cords with huge "wall wart" transformers?
The picture of the power supply is out of date. I just got the new ones today, and they are not the clunky wall warts. They're the modern, tiny switching power supplies with an interchangeable two prong cord for US and overseas voltages. I'll post a picture in a day or two.
We used the regulated wall-wart supply for the prototypes, because the switching supplies are more expensive, they have to be custom-ordered in large qty, and they take 8 weeks to get.
So why don't you go ahead and release the code with comments? And while you're at the it, the schematicwould be nice... And the contents of the configuration eeprom from the altera part... Gerbers, etc... ;-)
Sure - first you just have to convince me that there's enough interest in this low-level stuff that it's worth the risk of someone cranking out illegal clones.
SliMP3 is open, in the sense that you can hack the UI and make it do whatever you want, but it's not free as in free beer. Opening the hardware and device drivers would serve a hobbyist's educational interest, sure, but I don't see that our customers or our business would benefit significantly from it.
I have a home network that this could work with quite nicely?that is, other than the fact that I am going to dust off one of my 10/100 auto-sensing hubs just for this purpose and loose my bragging rights of having a completely switched, 100MB home network!!!
I think you're mistaken. AFAIK, there's no such thing as a 100Mbps *switch* that doesn't support 10Mbps, so SliMP3 would work fine on your network.
Hubs that only support 100Mbps are very hard to come by these days.
The firmware was posted (finally) for the PIC16F877 controlling the whole thing. Disassembly shows much of it is regular code, but some appears to be encrypted - ie, not real code.
:)
Heh - I was wondering how long before someone loaded it into MPLAB and disassembled it. The funny thing is, it's all written in assembler, so you're just a few comments away from having the source code.
The chunk from 0x0600 to 0x0x07FF that isn't valid instructions is actually string data - two 7-bit ASCII characters in each 14-bit program word, to save ROM space. The PIC16F877 can read it's own program memory, so this is more efficient than using a bunch of RETLW instructions like you had to do with the older PICs.
where can I buy a VFD?
The display we're using costs $92.2 in single QTY, and you can get them from Digikey.
Digikey carries the full Noritake line. They also have some smaller displays and some graphic ones.
how much power does a VFD consume?
There's a copy of the data sheet in our CVS repository if you're interested. The 40x2 uses about 450ma @ 5V, IIRC.
can one be plugged into a COM port?
No, it uses an 8 bit parallel interface, the same as standard LCD modules. The interface is pretty simple, I'm sure there are some examples out on the web of how to hook one up to your parallel port.
$250+ for an MP3 player that doesn't have it's own storage with a display that doesn't exactly look as professional as other MP3 players on the market...
Umm... not storing the files on the player is the whole point! The idea is that you can have two or three of these in different rooms of your home, and they can all be controlled idependently, with your music all stored in one place. So the amount of music you can access is not limited by the player, and you don't have to replicate your collection between several hard disks.
The display is vacuum fluorescent, as opposed to LCD. They're much more expensive than LCDs, and much more readable. I had trouble taking a good photo of it though - you really need to see it in person.
I chose to go with the VFD because even though it's expensive, the $30 price difference vs. the LCD is not a huge percentage of our cost right now. Some day, we'll might make a cheaper version with a backlit LCD. Right now it doesn't make much sense cost-wise, and people generally feel that the VFD is worth the $$.
And it's not even availiable yet! I wonder how CmdrTaco got his. A "free" review copy perhaps?
Yep, I sent him a prototype so he could write the review. The product will be available for sale in 1-2 weeks.
Sean
That clearly wasn't an argument, it was a statement. I don't think that way of stating the laws of thermodynamics is helpful in understanding them, by any means, but the laws of thermodynamics still hold.
/. tonight, and by that fact alone I feel as if some law of nature has been violated, so I'm satisfied. :)
Sorry, I was a little snippy because entropy is one of few concepts in physics that I've ever had trouble accepting.
Anyway, I actually learned something on
Excellent explanation, dragons_flight, thanks.
I will now grudgingly accept the known laws of physics, and find another field in which to seek my Nobel prize.
Interesting - I'd mod you up if I could.
It tells you that it's impossible to transfer energy from heat to any other form with 100% efficiency.
Sigh... as I've already said, I'm not arguing against conservation of energy (at least I hope I'm not doing so inadvertently).
It is possible to locally decrease the entropy of one system, but you are guaranteed to increase the entropy of everything else by at least the difference.
Exactly - *this* is what I want. Extract heat from the room as electricty for use later (or somewhere else). Sure, it's going to end up as heat again at some point.
I don't care if this is only 0.000001% efficient. I just want to know that it's possible.
So, if you want to just randomly generate electricity from a warm room, all you have to do is provide one exit for the warm air from the room, and have it lead to a colder room. You put a turbine in that passage, and you'll be able to convert the linear motion of the warm air moving into the cold room into rotational motion and turn a generator.
Agreed, but is this *necessarily* so inefficient as to be impractical? I.e. is it that it can't work, or have we just not figured out how to do it?
anyway, it still wouldn't answer my question. What I'm confused about is the following:
We can convert electricity directly to heat, without having to "cool something else down" in the process. Why doesn't it work in reverse?
OK, I'll bite. I just drove up there.
Here are some hilarious images of this classic f**cked company.
1.You can't win.
2.You can't break even.
3.You have no choice about playing.
That's a weak, if not utterly wrong, argument for entropy. I haven't studied thermodynamics, but entropy is something I've heard of, looked up in the dictionary, dug around for on google, etc, and frankly I have never seen a acceptable explanation of this "basic" law which so many take for granted. Why is it that it's always presented as some magical "incresing order of things"?
Heat *is* energy. We have ways of turning it into other forms of energy, they're just inefficient, and generally require temperatures above boiling.
Nobody is proposing that your laptop could power itself off the heat it generates. However, lots of systems are designed to recover some of their "wasted" energy. Electric cars have regenerative brakes, for example. This doesn't make them perpetual motion machines, it just gets them a little closer.
Will the experts please explain the following: why can't I extract heat from the atmosphere, and turn it into electricity/motion/whatever? We have no problem doing this if there's lots of heat (geothermal power plants), but why can't I have a sort of "reverse air conditioner" that works at room temperate?
It's also kind of stupid that you left your car on the street with only those puny door locks. That's why I stole it.
I think you got the wrong car. I left mine in the street with doors and windows open, the keys in the ignition, and the engine running, with a sign in the window saying "thanks for not stealing me".
4.2.2.4: i-will-not-steal-service.gtei.net
Kinda stupid, actually. "Hey, we've left our DNS servers accessible to the public with no access control, but please don't use them unless you're paying us"
Most people configure their DNS servers to allow anyone to do a recursive lookup, because usually there's no point in using someone else's DNS as opposed to running your own or using your ISPs.
If they wanted to prevent the public from using their DNS servers, they would have one set of servers only accessible to their own customers, and another set accessible to the world, but which only served domains they were hosting. It's very easy to do, so it's silly of them to insinuate that we're "stealing" by using name servers which have been deliberately left open.
FYI,
AT&T @Home service in Cupertino, CA is down. The lights on the modem are on, but changing DNS servers or typing IP addresses into the URL does not work. So it looks like the head-end is up, but nothing's getting routed.
I still feel like my $1K/mo T1 is a rip-off, but hey, at least it's up! Although I've heard rumors that XO (the CLEC providing the circuit to HE.NET) is also having financial troubles.
Looks like another win for the ILECs.
For example, it is possible to place a video server in the CO and a customer could order a movie and the bandwidth pipe between the video server and the subscriber would be opened up accordingly (say 4Mbps, while standard Internet (i.e. web) traffic would remain as it was (say, 512Kbps).
That's an interesting approach, and I there are definitely some applications for it. However, it's an awfully kludgy workaround to the original problem, i.e. that the cost of transmitting a packet depends on the destination.
I don't want my ISP to decide how much *bandwidth* I can have for a particular destination or service. I'd rather that they let me use whatever bandwidth I wanted, and charged me according to the cost of the next hops I use (or better yet, the full path).
Consider the implications this would have in furthering p2p technology, and driving the Internet to a more efficient structure. Content moves to the edges, performance improves, costs decrease. I'd be able to videoconference 24/7 with another customer on the same ISP for pennies a month, while my cross-country traffic is cheaper because those expensive paths are being used more efficiently. Instead of just selling a bandwidth limited pipe that's only good for web surfing, ISPs would become real communities, their value being the content and customers on their networks.
It'll happen. Our demand for bandwidth is insatiable, and this is the only way that huge pipes will ever be affordable for us and profitable for the ISPs.