Working for a company that builds an Inflight Entertainment system I can say that the lack of support for these kind of devices is the main reason for embedded systems like ours to NOT use Linux.
We have tried it, but every time we end up having to fight with vendors to get specs. I have written two MPEG decoder drivers for Linux that could never be released because of suck-ass NDA's.
btw. for your information: DVD CPU decode consumes about 10 Watts against about 1 Watt for a hardware decoder.
A lot of the recent PCI chips support CardBus. Most recent laptops have CardBus.
The company does not say they are making a PCI DVD-decoder card. They say they have a driver that they will GPL if they find a company to build a board. This board could be a CardBus board.
Also the page says: Interface to the graphics display subsystem (VGA)
What sort of interface? There are at least three ways to get decoded video to your VGA: 1) VGA loopback 2) ZV (Zoomed Video) or VMI or VPI or AMC 3) PCI
I suspect this to be the ZivaPC ref design. I hope it is, because it's a good chip.
But dude, TAPI (Toaster API) was released just after MAPI (Microwave API) in 1993 or so.
Microsoft was the only one to see the potential of Intel chips. Have you never wondered why it is they created the only OS lame enough to not run HLT instructions when idle? Too keep that heat up man!
Ghee, I can't believe the damn thing is still going to support Real and V86 modes... I wonder for how long we will be wasting transistors to support 8086 programs written in 1984 (which are probably not Y2K compliant and the source is lost so what's going to be left next January anyway?).
And what about this CPUID reg 2 - Processor Serial Number? I thought we agreed that that was not a Good Thing.
I though this IA-64 was going to be a 'fresh start' sort of thing. Like rid the old crap. I know IA has never been RISC, but even CISC doesn't seem to apply anymore.
Now put yer hands together fer Backwoods Compatibility.
From that link: 24. Red Hat 6.0 Official Release i386 Version SHIPPING $ 79.00
I imagine (s)he'd also rather not pay $79.00 Try this instead: LSL - you only pay shipping. (We received it last week, and it's up and running, although pretty slow on a 233MMX w 32MB RAM).
Breace
Re:I though people would learn...
on
LinuxExpo Report
·
· Score: 1
Anonymity is important. If you go around telling people that you have moderator access, I'll remove your access. It is essential to the system that moderators don't operate for ego inflation or fame or to promote their ideaology. We must be fair or the system just won't work.
Hmm, you must be confused about the D-Link. I don't think they have a 8029. They do have a Realtek 8029 clone though, but that's a 10Mb/s only chip. It's also a NE2*00 clone, which means that it's very unlikely to actually get anywhere close to 100Mb/s because of the silly I/O scheme. I imagine it was probably a DEC based board.
Anyways, that's a pretty fast system,- we don't have one in the office here. I'll certainly redo our tests though as soon as I can, because we do have NT4 now and I think you are right about us using 3.51. (Although most of our test are Raw Ethernet related, not TCP/IP)
We have an in-house OS (maybe one day I'll talk them into Open Sourcing it...) that's written almost entirely in C++. Works just fine. Performance absolutely great (we get full duplex 95Mb/s (in each direction) on the Ethernet while playing back an MPEG movie from harddisk on a K5-133)
The point is that the Linux kernel is not C++. I think it used to be compiled with the gpp compiler for a while but due to bugs in the compiler they switched back to gcc.
Video CD is MPEG-I, and DVD movies are stored using MPEG-II.
Video CD uses MPEG-1, layer I or II, not layer III which is MP3. Most MPEG-1 hardware decoders that I know of don't implement layer III decoding.
Most DVD movies use Dolby AC-3 for audio, not MPEG although I believe in Europe they do (but again layer I or II as I understand). I also know of no DVD decoder that integrates MP3 decoding.
I'm sure you are right, but can you please discribe the system (CPU, RAM etc?), just for us to get an idea. Because I've never been able to see such a thing. Then again, I think I gave up on NT when we still only had P90's...
BTW, if you ever want to convince yourself that ISA sucks, just run some tests on a PCI NIC and then an ISA NIC, and watch the 60-80% increase in CPU use for the ISA card
Right. Although we had a bad experience with the OPTi 802/832 PCI chipset. It doesn't implement DMA burst modes from RAM to PCI devices, and thus limits the max datarate in that direction to about 5MB/s. That's worse then ISA! Anyways, that's an other story altogether...:(
Thankx for letting us know about netperf. I wasn't able to connect to their ftp server yesterday.
That's 62 - 74 bytes overhead for 1500 bytes of data: 4.13% - 4.93% overhead, not 25%. And this is realistically _achievable_ throughput on a two node network.
We need some serious network benchmark tools that are cross-platform usable between Linux and Windows and maybe more.
Strangely enough not too many seem to exist. Neither does someone seem to have some hard data on network performance. It entirely useless to say 'I get 1MB/s using FTP'.
A good network benchmark tool will be able to test raw Ethernet performance as well as performance through protocol layers.
Of course it would only test the network and not use the file system or hard drive. It should be very clear what sort of configuration is supposed to be used: two systems running full-duplex, one system using remote loopback or whatever. It could also be interesting to have a > 2 system test to show what collisions do.
And most important as far as I'm concerned: Open Source. I don't believe in closed source benchmarks.
The difference between raw Ethernet and TCP/IP protocol would show us how badly we need hardware assistance on what platform.
Maybe we should try to port netperf ( www.netperf.org) to Windows and add raw Ethernet to it.
Well, maybe I'll be a bit more serious about this if there's an interest.
Exactly, this card is of interest because the Microsoft network stack is terribly slow, and costs an awful lot of CPU time.
The main reason for this is: Poor design. (What did you expect?)
The M$ network stack is (as with most M$ device driver architectures) way more complex to deal with then for example Linux and as a result many of the network drivers are not well written. E.g. they are not optimized for performance. I'm sure the writers are happy if the damn thing works at all.
The network stack itself also has much more involvement with each packet going out or coming in then with Linux. In some cases packets are actually copied in RAM. This is what causes the higher CPU overhead.
We have run several tests and the results where depressing. I think we probably lost the source code, but if I can find it I will post it somewhere.
Here's some of the figures I remember: (all tests where raw network tests, RAM to RAM, no hard drives involved)
Two P90 systems using 100Mb/s Full Duplex (DEC 21140) cards. We where unable to sustain more then 35Mb/s using UDP in one direction only.
Linux on this configuration: close to 100Mb/s.
Using a raw packet driver on a 200MMX notebook with a SMC 100Mb/s Full Duplex card and using remote loopback we are unable to get much more then 15Mb/s sustained. (That's 15Mb/s going out and 15Mb/s comming in) This was using raw Ethernet packets, no TCP/IP or other protocol.
This same configuration in a normal network is unable to receive more than around 4Mb/s UDP multicast packets, or packets will be dropped (thus not received)
I'm surprised that people have kept up with the poor raw network performance of our Redmondians. It's a disgrace, and I will NEVER use a M$ product if serious networking is to be done. Even if the Ethernet adapter handles the protocols.
(2) Have you considered how trivial it is to undetectably duplicate a paper signature? Moreover, how easy it is to lift a signature from one document and apply it to another?
Well, I have to say, maybe I've been watching Discovery Channel a bit too much lately, but this is certainly not true.
They (as in Big Brother) are very capable of figuring out whether something is an original autograph or not. Carbon copy systems for example often use different 'ink' that can easily be detected. Even if the ink could also be found in pens, then the structure of the copying material leaves marks for example. Obviously you wouldn't be able to see this with bare eyes, and for some of the details they actually use chemicals and special light.
It could be defined to be flexible as to advance as cryptography advances. I don't think it would be wise to state the actual number of bits of the key in a new law.
In my opinion it would be much better to phrase it along the lines of: "a legal signature is one created with an encryption method that takes at least 256 years to crack using todays (date of signature) largest amount of compute power available to a person or organisation."
Well, I'm not a lawyer, nor do I speak English natively, but I think you can get the picture.
Anyways, the weakness of encryption has long passed the era when the encryption algorithms where the weak point in the chain.
The weak point is you and me. At one stage or an other we have to type a password/phrase or a key or it could be something else, it doesn't matter. I'm sure that this is, even statistically, a much more likely place to hack an encryption system then a (relatively good) encryption method.
So maybe that's where our worries should be. Maybe there has to be a safer way to identify yourself before you can use your digital signature.
Finger print recognition? Or a physical signature? Ah, no, that's what we are trying to do away with...;o)
Well, I'm not saying Open Source chips (or Open Design), but Open Datasheets. For a start.
With datasheets I mean at least programming information, so that drivers can be written for OS's like Linux or others.
I find that a lot of the time my company (one of those small ones) is just not able to use a certain chip because we DON'T want to use M$ products (in our embedded environment, strange uh?). This means we can't use the factory M$ drivers, which means we need datasheets to write our own drivers for our own OS (or Linux).
Mainly the larger chip makers that don't have their datasheets available on the Web are a pain in the neck to get in contact with - example - NeoMagic: they don't even want to put me through to sales, let alone tech support. We don't fit in their business-plan, too small. So we use C&T because they have their datasheets readily available on the Web.
I don't believe that providing programming information for a device gives away your internal design: if I want to know the programming info real badly I will get it anyway through reverse engineering. Believe me, I have done it.
An other excuse that is used is that they don't want to 'support' the effort of third-parties writting device drivers.
Which is complete crap. If the datasheet is good, no one needs support to write a driver. For the drivers I have written (I guess about 12), I have only contacted the manufacturer twice. The first time to tell them the datasheet had errors the second time to tell them their silicon had errors.
And how difficult would it be to sell a couple of more chips to little companies like ours?
I still hope for Open Datasheets but I'm sure Open Source chips will come too. The biggest part of a chip is actually software anyways (VHDL, Verilog).
Slashdot Mirror
Working for a company that builds an Inflight Entertainment system I can say that the lack of support for these kind of devices is the main reason for embedded systems like ours to NOT use Linux.
We have tried it, but every time we end up having to fight with vendors to get specs. I have written two MPEG decoder drivers for Linux that could never be released because of suck-ass NDA's.
btw. for your information: DVD CPU decode consumes about 10 Watts against about 1 Watt for a hardware decoder.
Breace.
A lot of the recent PCI chips support CardBus. Most recent laptops have CardBus.
The company does not say they are making a PCI DVD-decoder card. They say they have a driver that they will GPL if they find a company to build a board. This board could be a CardBus board.
Breace.
Anybody know's what chip(set) is used?
Also the page says:
Interface to the graphics display subsystem (VGA)
What sort of interface? There are at least three ways to get decoded video to your VGA:
1) VGA loopback
2) ZV (Zoomed Video) or VMI or VPI or AMC
3) PCI
I suspect this to be the ZivaPC ref design. I hope it is, because it's a good chip.
Breace.
'but what other toaster has an operating system'
:o))
But dude, TAPI (Toaster API) was released just after MAPI (Microwave API) in 1993 or so.
Microsoft was the only one to see the potential of Intel chips. Have you never wondered why it is they created the only OS lame enough to not run HLT instructions when idle? Too keep that heat up man!
(Sorry, I just had to
Breace.
Ghee, I can't believe the damn thing is still going to support Real and V86 modes... I wonder for how long we will be wasting transistors to support 8086 programs written in 1984 (which are probably not Y2K compliant and the source is lost so what's going to be left next January anyway?).
And what about this CPUID reg 2 - Processor Serial Number? I thought we agreed that that was not a Good Thing.
I though this IA-64 was going to be a 'fresh start' sort of thing. Like rid the old crap. I know IA has never been RISC, but even CISC doesn't seem to apply anymore.
Now put yer hands together fer Backwoods Compatibility.
Breace.
Blink, darn...
Uh, no not stupid or funny, just blind.
Breace.
Just remember, there are no stupid questions, just stupid people. - SP
Huh?
From that link:
24. Red Hat 6.0 Official Release i386 Version SHIPPING $ 79.00
I imagine (s)he'd also rather not pay $79.00
Try this instead: LSL - you only pay shipping.
(We received it last week, and it's up and running, although pretty slow on a 233MMX w 32MB RAM).
Breace
From the Moderator Guidelines:
Anonymity is important. If you go around telling people that you have moderator access, I'll remove your access. It is essential to the system that moderators don't operate for ego inflation or fame or to promote their ideaology. We must be fair or the system just won't work.
Nuff said.
Breace.
Hmm, you must be confused about the D-Link. I don't think they have a 8029. They do have a Realtek 8029 clone though, but that's a 10Mb/s only chip. It's also a NE2*00 clone, which means that it's very unlikely to actually get anywhere close to 100Mb/s because of the silly I/O scheme. I imagine it was probably a DEC based board.
Anyways, that's a pretty fast system,- we don't have one in the office here. I'll certainly redo our tests though as soon as I can, because we do have NT4 now and I think you are right about us using 3.51. (Although most of our test are Raw Ethernet related, not TCP/IP)
Thankx for letting us know.
Breace.
We have an in-house OS (maybe one day I'll talk them into Open Sourcing it...) that's written almost entirely in C++.
Works just fine. Performance absolutely great (we get full duplex 95Mb/s (in each direction) on the Ethernet while playing back an MPEG movie from harddisk on a K5-133)
The point is that the Linux kernel is not C++.
I think it used to be compiled with the gpp compiler for a while but due to bugs in the compiler they switched back to gcc.
Breace.
Looks like an excellent study to me.
One little thing, your network card:
DEC 21040 based AsanteFAST 10/100Mbps ethernet cards
Should probably be DEC 21140. 21040 is only 10Mb/s.
Breace.
Video CD is MPEG-I, and DVD movies are stored using MPEG-II.
Video CD uses MPEG-1, layer I or II, not layer III which is MP3. Most MPEG-1 hardware decoders that I know of don't implement layer III decoding.
Most DVD movies use Dolby AC-3 for audio, not MPEG although I believe in Europe they do (but again layer I or II as I understand).
I also know of no DVD decoder that integrates MP3 decoding.
Too bad really...
Breace.
I've seen NT get 90+Mbps on a 100Mbps ethernet
:(
I'm sure you are right, but can you please discribe the system (CPU, RAM etc?), just for us to get an idea. Because I've never been able to see such a thing. Then again, I think I gave up on NT when we still only had P90's...
BTW, if you ever want to convince yourself that ISA sucks, just run some tests on a PCI NIC and then an ISA NIC, and watch the 60-80% increase in CPU use for the ISA card
Right. Although we had a bad experience with the OPTi 802/832 PCI chipset. It doesn't implement DMA burst modes from RAM to PCI devices, and thus limits the max datarate in that direction to about 5MB/s. That's worse then ISA! Anyways, that's an other story altogether...
Thankx for letting us know about netperf. I wasn't able to connect to their ftp server yesterday.
Breace.
No you don't understand.
With Linux you don't need multiple processors to sustain decent Ethernet throughput.
Breace.
Using an other system doing the remote loopback, or simply wiring TX to RX on the system that's being tested itself.
Sorry about the confusion.
Breace.
Let's see:
preamble & start frame = 8 bytes
Ethernet header = 14 bytes
UDP header = 28 bytes (TCP = 40 bytes)
DATA (not counted as overhead) = 1500 bytes
CRC = 4 bytes
Interpacket gap = 8 bytes
That's 62 - 74 bytes overhead for 1500 bytes of data: 4.13% - 4.93% overhead, not 25%.
And this is realistically _achievable_ throughput on a two node network.
Breace.
One thing is becoming obvious.
We need some serious network benchmark tools that are cross-platform usable between Linux and Windows and maybe more.
Strangely enough not too many seem to exist. Neither does someone seem to have some hard data on network performance. It entirely useless to say 'I get 1MB/s using FTP'.
A good network benchmark tool will be able to test raw Ethernet performance as well as performance through protocol layers.
Of course it would only test the network and not use the file system or hard drive. It should be very clear what sort of configuration is supposed to be used: two systems running full-duplex, one system using remote loopback or whatever. It could also be interesting to have a > 2 system test to show what collisions do.
And most important as far as I'm concerned: Open Source. I don't believe in closed source benchmarks.
The difference between raw Ethernet and TCP/IP protocol would show us how badly we need hardware assistance on what platform.
Maybe we should try to port netperf ( www.netperf.org) to Windows and add raw Ethernet to it.
Well, maybe I'll be a bit more serious about this if there's an interest.
Breace.
O common, what do you expect?
;o).
Can we please be serious about this. 1MB/s is nothing. If win95 wouldn't be able to even sustain that...
Let us know when you get >10MB/s with a 100Mb/s board.
btw. please get your capitalization correct: MB = Mega Byte, Mb = Mega bit, mb = I dunno
Breace.
I guess on a Half Duplex that's acceptable (depending on the entire network usage though), but on Full Duplex I would wonder where the other 25% went.
Breace.
Exactly, this card is of interest because the Microsoft network stack is terribly slow, and costs an awful lot of CPU time.
The main reason for this is: Poor design. (What did you expect?)
The M$ network stack is (as with most M$ device driver architectures) way more complex to deal with then for example Linux and as a result many of the network drivers are not well written. E.g. they are not optimized for performance. I'm sure the writers are happy if the damn thing works at all.
The network stack itself also has much more involvement with each packet going out or coming in then with Linux. In some cases packets are actually copied in RAM. This is what causes the higher CPU overhead.
We have run several tests and the results where depressing. I think we probably lost the source code, but if I can find it I will post it somewhere.
Here's some of the figures I remember: (all tests where raw network tests, RAM to RAM, no hard drives involved)
Two P90 systems using 100Mb/s Full Duplex (DEC 21140) cards. We where unable to sustain more then 35Mb/s using UDP in one direction only.
Linux on this configuration: close to 100Mb/s.
Using a raw packet driver on a 200MMX notebook with a SMC 100Mb/s Full Duplex card and using remote loopback we are unable to get much more then 15Mb/s sustained. (That's 15Mb/s going out and 15Mb/s comming in)
This was using raw Ethernet packets, no TCP/IP or other protocol.
This same configuration in a normal network is unable to receive more than around 4Mb/s UDP multicast packets, or packets will be dropped (thus not received)
I'm surprised that people have kept up with the poor raw network performance of our Redmondians. It's a disgrace, and I will NEVER use a M$ product if serious networking is to be done. Even if the Ethernet adapter handles the protocols.
Breace.
Apparently not. I can't access their site right now. /.'ed allready. :o)
Breace.
(2) Have you considered how trivial it is to undetectably duplicate a paper signature? Moreover, how easy it is to lift a signature from one document and apply it to another?
Well, I have to say, maybe I've been watching Discovery Channel a bit too much lately, but this is certainly not true.
They (as in Big Brother) are very capable of figuring out whether something is an original autograph or not. Carbon copy systems for example often use different 'ink' that can easily be detected. Even if the ink could also be found in pens, then the structure of the copying material leaves marks for example. Obviously you wouldn't be able to see this with bare eyes, and for some of the details they actually use chemicals and special light.
Breace.
Why would the encryption schema be fixed?
;o)
It could be defined to be flexible as to advance as cryptography advances. I don't think it would be wise to state the actual number of bits of the key in a new law.
In my opinion it would be much better to phrase it along the lines of: "a legal signature is one created with an encryption method that takes at least 256 years to crack using todays (date of signature) largest amount of compute power available to a person or organisation."
Well, I'm not a lawyer, nor do I speak English natively, but I think you can get the picture.
Anyways, the weakness of encryption has long passed the era when the encryption algorithms where the weak point in the chain.
The weak point is you and me. At one stage or an other we have to type a password/phrase or a key or it could be something else, it doesn't matter. I'm sure that this is, even statistically, a much more likely place to hack an encryption system then a (relatively good) encryption method.
So maybe that's where our worries should be. Maybe there has to be a safer way to identify yourself before you can use your digital signature.
Finger print recognition? Or a physical signature?
Ah, no, that's what we are trying to do away with...
Breace.
Well, I'm not saying Open Source chips (or Open Design), but Open Datasheets. For a start.
With datasheets I mean at least programming information, so that drivers can be written for OS's like Linux or others.
I find that a lot of the time my company (one of those small ones) is just not able to use a certain chip because we DON'T want to use M$ products (in our embedded environment, strange uh?). This means we can't use the factory M$ drivers, which means we need datasheets to write our own drivers for our own OS (or Linux).
Mainly the larger chip makers that don't have their datasheets available on the Web are a pain in the neck to get in contact with - example - NeoMagic: they don't even want to put me through to sales, let alone tech support. We don't fit in their business-plan, too small. So we use C&T because they have their datasheets readily available on the Web.
I don't believe that providing programming information for a device gives away your internal design: if I want to know the programming info real badly I will get it anyway through reverse engineering. Believe me, I have done it.
An other excuse that is used is that they don't want to 'support' the effort of third-parties writting device drivers.
Which is complete crap. If the datasheet is good, no one needs support to write a driver. For the drivers I have written (I guess about 12), I have only contacted the manufacturer twice. The first time to tell them the datasheet had errors the second time to tell them their silicon had errors.
And how difficult would it be to sell a couple of more chips to little companies like ours?
I still hope for Open Datasheets but I'm sure Open Source chips will come too. The biggest part of a chip is actually software anyways (VHDL, Verilog).
Breace.
Yeah, why buy a Global if you can afford a 777?
x .html
http://www.boeing.com/commercial/777family/inde
Then you can reserve an area for tennis or something. And a shower/bath afterwards.
Breace.