First off email is going to be afected very little because there won't be MX records in the zone and port 25 won't answer. So the end user will get back an error message. Life will go on without bad things happening. Peer to peer will be much the same.
Well there's three breakages already:
DNS says the domain is valid, but there's no MX records - which gives an error something like "No MX records for this domain/host" instead of "Domain/host doesn't exist".
DNS says the domain is valid, the emailer somehow tries the host directly (which you could configure it to do) and finds it's not responding. This gives the error "Host not responding" rather than "Host doesn't exist".
Peer-to-peer apps will try an address and it won't respond. This gets treated internally "Host not responding, try later" rather than "Host doesn't exist, delete from list".
Secondly, in the real world IE won the browser wars, live with it. The end users voted with their mice.
I think that at least one justice system has found this to be untrue - users didn't vote with their mouse, it was won by illegal means. I mostly agree with that ruling. The world is more than just Windows and IE - that's what a proper platform independent protocol is supposed to be all about.
NAT is a hack. It also makes a mess of transparency and isn't 100% in the minority of cases. However, the minority of cases usually break completely. Even things like Quake broke originally until the protocol was modified and people put in special handling in their NAT stuff.
But NAT isn't a fair analogy at all. People use NAT on their home networks, office networks, and other small LANs. Or simply as a poor man's firewall. We're not asking VeriSign (or a local cache) for information on how we should NAT. It's a local hack with the locals completely understanding that it's in there. VeriSign's DNS hack has global effect and can't be turned off.
Unless, of course, you filter the response of "198.41.1.35" (what they return) to mean "host not found". But that would be a hack to fix another hack... which is usually how these poorly thought out "fixes" end up...
The real story, just like the IAB says, is that it's a hack, and it messes with the distinction between application and service.
Here's an analogy: let's say you try to implement a method to display a pop-up search window when an executable file is not found. The obvious and clean way to do that is at the application level. When the application gets "file not found" from the filesystem, it arranges to pop up a search window. You'd only resort to alternate means if you can't modify existing applications.
Alternatively, you could implement a hideous hack where the file system instead opens a default executable. The application then never knows that the file wasn't found and executes it. It's achieved the same end, but it'll have a lot of side-effects. For a start, the application may not have wanted to execute it. It might even be trying to detect whether it exists. Other applications may not be expecting that behaviour and it'll break them. Another operating system may have that file system remotely accessed and end up running a non-native executable when it was looking for a native one. And years later, developers will still be working around this messed up behaviour because hacks are hard to get rid of once they are deployed at large.
DNS is not supposed to be a "lookup service for http transfers". Assuming that every lookup will be because of web browsing (by IE no less) is stupid. It's not even a good hack. As someone else who has replied to this article has pointed out it may not even cover the majority users. What about all those email servers bouncing email all over the place? What about all the peer-to-peer users? VeriSign would end up getting an enormous amount of non-web related connections hitting their "default IP".
VeriSign may be trying to get something out the door, but they could at least have implemented one of the preliminary specs (like simple UTF-8 encoding or mangling). Not a hack which only works for http transfers initiated specifically by IE, which breaks every other protocol and every other application.
At what clock rate? The Game Boy Advance has a single ARM7TDMI at 16.8 MHz, and it's generally accepted that the GBA can't decode MP3 without extra hardware on the cart.
Presumably enough to at least do MP3. Vorbis (with the Tremor decoder) takes roughly the same amount of MIPS.
The 5002 is a dual ARM7TDMI processor. I've worked on lots of ARM based products and I can say with certainty that a single ARM7TDMI has plenty of CPU left over after decoding MP3, WMA or Vorbis. Actually, you could probably decode two MP3 streams simultaneously with MHz to spare.
Perhaps you're not understanding that this isn't a "hardware mp3 decoder" chip - it's a general purpose CPU with approximately the processing power of an Intel 486 66-100MHz (depending on what you're doing). Provided the codec you want isn't too MIPS (or memory) hungry, you could software upgrade to support it.
How is the Xscale an improvement to the StrongArm SA-1100?? Is there a comparison?
There's no point-by-point comparisons I can find, but I'm very familiar with both. The main improvements on the XScale are:
ARM-9e instruction set. This adds saturate add/sub and 16x16->32 MACs from packed 16 bit data (but NOT SIMD). There's also a handy single cycle CLZ instruction (count leading zero bits), and a prefetch load instruction (PLD).
Hit-under-miss memory load operations. A read (ldr) which misses in the cache stalls at the point where the destination register is used, not on the ldr instruction.
64 bit load/store (LDRD/STRD). This appears to take pretty much the same time as two 32 bit ones, so my guess is it's just for code density.
16 bit fast multiplier with early-out. In comparison, ARM7*M has an 8 bits per cycle multiplier, and StrongARM has a 12 bits per cycle one (both also early-out). If you restrict yourself to 16 bit coefficients, you can manage a throughput of 1 MAC per cycle (with 2 cycle result latency).
An extra 40 bit accumulator. This works with a very limited set of instructions - 16x16->40 MACs, and 2x16x16->40 MACs. The idea is you don't have to worry about overflow for 256 operations. It appears to have the same throughput as the ARM-9e instructions otherwise.
Branch prediction with 2 slot history. This makes branches single cycle on correct prediction, and 5 cycles on misses. ARM7 is 3 cycle and StrongARM is 2 cycle.
However, there's a few things that aren't as fast, but can be mostly worked around by the compiler, or hand coded:
Loads have a result latency of 3 clocks (under cache hit). ARM7 would always stall for 2 (or was it 3?) clocks, but StrongARM would would simply have a result latency of 2 clocks. This needs taking into a account by the compiler or there'll be a noticable performance hit. Looking at gcc-2.95.3 for example, this isn't taken into account.
The branch prediction doesn't handle the case of loading directly into the program counter (e.g, ldr pc,[r0] like a switch statement would do). These act like misses and take 5 cycles (I think).
Load- and store-multiple (ldm/stm) is actually slower than a sequence of single load/stores - it takes an extra 2 clocks. Legacy code will run a tiny bit slower, and compilers need tweaking to take it into account.
A lot of the multi-cycle result instructions stall in issue for a few cycles when you specify condition codes for write-back, instead of taking just one issue cycle.
The result is that if your compiler groks XScale and you recode all the critical hand coded assembler, you'll get more than just the clock speed increase. If you run "legacy" code you'll most likely get a speed decrease vs the ratio of clock speeds, unless you happen to be stupidly heavy on multiplies and branches.
Aside from all that, it's got a lot of extra peripherals which are handy for embedded devices. It's quite likely I'll be working on an XScale platform soon, and I'm rather looking forward to it.
MMX does not stand for "multimedia extensions", it stands for "matrix math extensions."
Intel's own marketing of MMX is inconsistent. In any case, XScale doesn't have what Intel refer to as "MMX" - but I thought I'd answer what the parent poster most likely meant.
I wonder if intel will stick their finger out and put some optimisations into gcc or linux for their MMX extentions.
The "Multimedia extensions" on the XScale come in two forms: the ARM-9e extensions and their own 40 bit multiply-accumulator coprocessor. It'd be nice to see the ARM-9e extensions in gcc as other processors would also benefit - not just XScale. This would be fairly easy to generate code for as you can "simply" replace two adds/multiplies with a single one in many cases.
The coprocessor is another matter and needs a lot of work from the compiler to get any speed increase out of its use. Last I looked at the processor documentation, I didn't see much advantage to using the coprocessor at all, even when hand coding assembler - the ARM-9e extensions give you pretty much the same speed increase anyway.
There's already phone lines installed in all the buildings (I'm guessing), so how about using something like HomePNA?
I'm not sure if it'll manage 100m, and you may have to play about with the wiring at both ends so there's as little as possible in the way, but it might do the trick. Besides, it's pretty inexpensive to try out. I've played about with PNA on relatively complex networks and the obstacle is usually the number of splitters/connections and not the distance travelled. I've never tried it as far as 100m, though:)
It sounds odd to me that you can't just pull some CAT5 through where the existing phone lines are. Or, replace a phone line with a CAT5 and use an unused pair for the phone line it replaced. I think 100m is around the maximum that ethernet will go down CAT5.
If cost is no object, you could peg up a GPRS link using a mobile phone:)
Me, I'd try PNA, seeing as that needs no extra messing about with cables. If that fails you seriously need to think about dragging CAT5 through where you've already got your phone lines installed. You might even be able to get ethernet down the phone cabling - I believe (UK) phone cable is still twisted pair, just not screened (or is it the other way around?). But I don't know enough about the issues there to comment more.
Removing unsigned types is a good idea when doing computation, so that bad code like unsigned i; for (i = count-1; i >= 0; i--) foo(i); won't happen.
Any compiler worth its salt will see "i >= 0" and will give a warning "Range comparison is always true". As a bonus, if you do allow unsigned types, "i
Unsigned types also improve performance on most processors. Division by a power of 2 is just a shift if it's unsigned. With signed numbers it's a shift, compare and conditional add. This optimisation cannot be determined at compile time unless you define the type as unsigned.
The only architecture I can think of where unsigned types are slower is Motorola 56k, which has so many other things wrong with it that it's not surprising. It's certainly (significantly) faster to use unsigned where possible on all non-DSP-oriented processors I can think of (x86, ARM, PPC, 68k, PIC, 6502...)
I also found your comment on "up." interesting. For me, my thumb is about in the position of 'n' and it is uncomfortable to move it across 3 places. However, since you are a pianist, I would guess you are pivoting on the 'p' and swinging the thumb across, which you would be very used to doing on the piano (this also seems to be transferring the weight of your hand over to the right - so how would you type "up.ya") ?
My thumb also rests naturally on 'n'. For the '.' on 'up.', I basically pivot my thumb on to '.' without moving my hand at all. It's much like ascending a scale on the piano - you play a few notes upward then "tuck" your thumb under for the next note so you can pivot your whole hand over to the next set. In this case I'm finishing a word so it's just a handy "free thumb" to use which doesn't require me moving my hand at all. I can stretch my hands to fairly ridiculous amounts, though, so I don't know how other people's mileage may vary:)
Runs on the same hand are faster than alternation, sure. But alternation is much faster than arbitrary motions of one hand. Given the variety in English, optimizing for long runs will win on a very few words, and screw up the layout for everything else. I challenge you to refute this.
If all English words were made up of random letters, and had uniform occurance, this would be obvious. But because some words are vastly more common than others, and have a lot of similarity, this isn't so obvious. As you say, Dvorak promotes some runs like th, sh, wh - so why not extend to promote runs longer than two? You don't need to restrict to adjacent keys - so long as there's a different finger near the next key it'll be nearly as fast. However, my argument regretably lacks any data to back it up - much like yours does.
I might agree about the natural position of the fingers (though I suspect the natural position is actually somewhere in-between asdf and awef). But the idea that each finger can be on its own row is just wrong for normal hands. Ask some normal people to try it, and they'll tell you.
I see what you mean about it being somewhere in between. Perhaps I shouldn't have been quite so wide-sweeping with "one finger per row" statement. Some combinations are obviously ridiculous and would likely cause injury to yourself and the nearest 3 people. Other combinations aren't difficult and probably strain less than moving all of your fingers at once.
In general, my style tends towards "smoothing out" the stretching of fingers and movement of the wrists by predicting the required positions of each hand and moving progressively towards an optimum position for it. I agree that this is unusual, but I think that most people could learn this given time.
Unfortunately this program uses the same faulty assumptions that Dvorak used to design his keyboard layout. Namely the following:
Alternating between hands each key is fast
Hands are not allowed to move left or right
All four fingers on each hand must rest on the same row
Moving up or down a row is slow, because of the above
You don't use your thumbs except for space
Where did these assumptions come from? I've got about 15 years of piano playing under my belt, and I find the standard "touch typing" rules very strange choices indeed. I type in a pretty free-form style at about 150wpm, depending on coffee. So, I'll disprove these assumptions one by one:
Alternating between hands each key is the absolute hardest action to do quickly. If you have a piano piece which has a segment like this (there's a few famous pieces like this) it'll either be relatively slow or you'll be practising it for months. Runs of keys in the same hand are far faster. I'd say about 5 times faster.
Why are hands not allowed to move left or right? If you have 8 keys to press, all of which reside to the right of the 'D' key, I move my left hand right a few keys! What's the point in keeping it where it is and making your right hand do more work and even stretch to reach the central columns?
Why must all 4 fingers rest on the same row? For a start, your fingers aren't even the same length! Place your hands naturally on a table, and compare to where the keys would be. You'll find that they would have been on "a,w,e,f" and "j,i,o,;". Somewhat luckily, qwerty keyboards have all of the vowels except "u" under these keys. There's no reason you can't have your fingers over arbitrary rows. With a bit of hand strength building, this is easy.
Moving up and down rows is only slow if you "float" above the keyboard (not resting your wrist on the table/rest) and move your entire arms back and forward. This would be an awful technique to use and I'd suspect it would lead to strain problems very quickly. Stretching your fingers forward and backwards is fast. And with the previous point, this is mostly irrelevant anyway.
So, why aren't we allowed to use thumbs for typing normal keys? It's perfect for hitting keys on the bottom row when all the others have been tied up. Just then, I typed "up." with right hand "2-4-1" (where 1 is thumb, 5 is little). Why? Because when fingers 2,4 have been tied up on the top row, the most convenient finger to use is my thumb. Try it.
Not to discourage trying to find new keyboard layouts too much, but it's best to start really from scratch and question the basis of all the original assumptions. The rules need to include:
Model the positioning of the hands and fingers in detail. If you remove the restrictions that "touch-typing" enforce, then the key-to-finger mapping also depends on context.
Encourage runs of keys in the same hand. About 3-4 keys in the same hand before switching is optimum.
Discourage rapid switching between hands (every key, for example).
My theory about carpal tunnel and other typing related injuries is that "touch typing" is actually to blame. It encourages stiffening of the wrists and hands, discourages stretching, and generally leaves your hands as weak as they were before you started typing.
My advice to anyone that uses classical "touch typing" is to learn to the point of about 40wpm, and switch to improvisation. My advice to anyone wanting to switch to Dvorak for speed, or to reduce strain: it's ultimately limited by the speed of one-key-per-hand switching which is about 120wpm. From my experience with both, you're better off sticking with qwerty and going free-style.
I haven't worked on X-Scale cpus, but I've certainly worked a ton on StrongARMs. A StrongARM SA-1100 has 16KB code and 8KB data cache. It's half-line 'dirty flag' write-back, 32 bytes per line, 32-way associative, and round robin evicted. The cache is very rarely the bottleneck - low MHz is more often the problem.
It's usually pretty hard to thrash a code cache to the point of it being the bottleneck. You pretty much have to deliberately write code to do that. For reference, an Athlon has a 64KB code cache, and that's running at a far higher speed than both of these ARM processors. Your figure of 50-100 million ops/second assumes an unreasonable 100% instruction cache miss rate. You'd have to have a program totally devoid of loops to achieve that. At a still unreasonable hit rate of 95% you'd still get 96% ((95*400+5*100)/40000) of full performance.
My guess why the real world performance is so bad is probably Microsoft's lack of optimization specific to the processor. There's a few trade-offs Intel have made to get the clock higher, including:
The latency of the barrel shifter is now 1 clock, instead of free. The compiler will no doubt assume the latter, as will tons of hand coded assembler.
The multiplier has higher latency (I think), but you can pipeline it along side loads, stores and arithmetic (nice). It won't have been compiled for this.
Loads/stores have higher latency, but you can pipeline them along side other stuff. The load/store multiple instruction has been "obsoleted" such that it's slower than separate instructions. That's pretty major for a compiler to ignore.
I certainly wouldn't expect to be able to take code targetted for StrongARM and see all of the performance increase that 200->400 would indicate. I can imagine hand coding assembler to work around the latencies and getting near to 100% performance. It's not that hard for a modern compiler to work this out either - a current day x86 is far more difficult to target than an X-Scale.
I see geeks come out with this crap a lot - it's as if they treat the law like it was computer code, and take the most twisted but literally plausible interpretation that suits their case.
You mean like lawyers do with... the law? The truth (and I mean that quite literally) is that every tiny little plausible interpretion of the law is exploited when it's to somebody's advantage. Intent doesn't matter, application is blind in the hands of expensive lawyers or large corporations. See Scientologists for a prime example. It does actually happen.
Banning direct links obviously doesn't work, which is why you say it's "reasonable" to also ban indirect links of any length. So option 2 is obviously out. That leaves us with:
Don't ban links.
Ban indirect links of any length.
There are many examples, papers, discussions etc on how most web pages are indirectly linked to another. Following your own logical progression, it would therefore be "perfectly reasonable" for a ban to include the entire web. Obviously that would be silly. Which leaves us with the remaining option:
Don't ban links.
It's as simple as that. This is why law is in general really twisted and complicated - it gets far too wide reaching otherwise. Sounds to me like this judge hasn't quite grasped the consequences that result from this. Or the logic, for that matter. IANAL, blah.
How about you look up which CPUs they use?
on
The Future of Ogg Vorbis
·
· Score: 5, Informative
I think I could answer that far more accurately (see my user info page). Guess what, most of the "good" MP3 players use ARM based CPUs:
empeg/Rio car player: StrongARM 220MHz, roughly equivalent to a Pentium 133 without FPU/MMX. Plays MP3s fine at a tiny fraction of CPU.
iPod - Portal player dual ARM-7 core 74MHz, roughly equivalent to a 486-100 without FPU/MMX.
Rio Receiver: Cirrus 7212 ARM7-TDMI 74MHz. Plays MP3/WMA.
Rio Central: StrongARM 220MHz. Plays MP3/WMA.
They are decent processors - you can do MP3/WMA/Whatever without an FPU. Hell, you can play Quake on them at a reasonable speed. Same goes for Vorbis - it "just" needs an integer implementation, which is rather a large task that nobody in the public domain wants to take on, and no business wants to spend development time on.
Re:Most embedded systems don't have an FPU
on
The Future of Ogg Vorbis
·
· Score: 3, Interesting
The way you state this sounds like as if Vorbis can't be done with integer-only artihmetic, which is false.
Sorry, didn't mean to have that impression come across. The main problem is that it's going to take a long time to rewrite all of the algorithms for integer. It's a shame really, because it would have taken just about as long to write it in integer in the first place. Floating point isn't the magic bullet everyone makes it out to be - it doesn't eliminate truncation and it certainly doesn't eliminate word size issues.
Actually, I find DSP code written in integer easier to understand because you can see exactly where the author is taking care of those issues much more clearly. In floating point it's all a bit magic, and in most cases they just didn't realise what's actually going on.
There's integer decoders for MP3 and WMA (and all sort of other codecs), so I agree there's no particular reason Vorbis couldn't be either. In fact, there are integer implementation of Vorbis - the trouble is Xiph want to sell them. Fair enough, but hardly anyone's going to buy it, and you've got to weigh that against the market penetration you'd get if it were free. Maybe they've got it right, but it still annoys me that, for example, I couldn't add Vorbis to an empeg car player because integer Vorbis isn't free, and I don't have the spare time to write an integer version.
For example, I am not aware of any flash portable pocket player that has an FPU. That's because it's entirely possible to do MP3/WMA in integer. Nobody is going to fit an expensive and battery draining processor into their product just to support an extreme minority codec.
By using floating point for the algorithms, libvorbis is ruled out from nearly all embedded devices. At the moment it pretty much only runs (in real time) on PC/Mac systems.
If you want people to listen to you, then you should give them enough credit to provide them with the information and rationale that you used to come to your conclusions rather than just telling us parrots what to repeat.
I don't see any of the UWB promoters giving me enough information to support their claims. Very well, I'll fill in some of the blanks I admittedly left:
1. What is COFDM?
Coded orthogonal frequency division multiplex. It splits the information on many (typically thousands) or carriers. Basically you take a bunch of bits to form a symbol. FFT that (kind of) to get the amplitude of each carrier, and transmit. To receive: modulate down to baseband, inverse FFT. Well, actually that's OFDM. COFDM modifies the output bits before modulation so the carriers are less susceptible to multipath.
See
this paper on OFDM/COFDM
2. What kind of bandwidth, range can I get out of it?
Pretty much any, depending on how you pick the number of carriers, bandwidth, signal strength, and carrier coding. In digital audio/video broadcast, it goes 2 - 68km, at 5 - 32mbit, using just 8MHz of bandwidth. See
this paper
3. Why isn't the industry pushing COFDM?
They don't need to. Digital Video and Digital Audio broadcast in the UK and (I think) some of Europe already uses COFDM. 802.11a already uses OFDM (it's only short range so you don't need the multipath protection). Everyone (except the US digital broadcast people, much to their disadvantage) already recognises it as "the thing to use".
4. How expensive is it to integrate COFDM onto a small device, such as a PDA?
Depends on the bandwidth and whether you offload all of the modulation into hardware or some in software. You've probably seen articles about Microsoft wanting to push processing of wireless lans into software
(article). I haven't got any figures and I probably wouldn't be able to find any without NDAs. My ball-park guess would be from no milliwatts for 10kbit+, to 100mW+ for 1mbit+.
5. What's the spacial capacity?
Depends on choice of number of carriers, carrier modulation scheme, error correction etc. There's probably theoretical limits, but it's very versatile.
6. How much power does it use?
Ditto. It's not very suitable for very low power (milliwatt) devices - you're better off with bluetooth then. You can get lower power by reducing the number of carriers, error correction, etc which also lowers your data rate. I have no idea which uses less power. UWB will certainly use up a fair bit of power with its high speed pulse train. Still, you'd probably use something simpler like bluetooth in really low power low data rate devices anyway.
As far as spatial capacity goes, it's not at all an indicator of whether one technology is better than another. It says only whether you can get that data rate at the maximum distance you require. So for short range usage, all of your examples will work. What's important then is power vs data rate. I can't say any more as to which is more suitable because I don't have a figure for ODFM, PSK and all the other reasonable existing technologies, nor do I have one for UWB. It would be hard to give a definite figure anyway - it would depend on assuming a particular implementation is optimal.
Read any book on signal processing. In fact, read anything that shows the relationship between time domain and frequency domain. It's a carefully managed scam that everyone seems to be swallowing. They've been writing their press releases up as if it's a "renegade" technology of some kind, in an effort to get some kind of sympathy for it. The reason the FCC and other communications bodies are so concerned about it is because they can see through the marketing:
UWB does use the spectrum. A large amount of it. It doesn't matter that it's at a really low density - it's still there. Put enough of these units in a small space (or more in a large space) and people will start noticing.
UWB does have a carrier. It's the entire spectrum. Or rather, because it's not the theoretical perfect pulse train that marketing is making it out to be - it uses a large segment of the spectrum. Think of it like this: FM radio uses a lot of power in a narrow band of frequencies. UWB has the same signal:noise but it spreads the power over a huge range of frequencies. Look at COFDM, which is a spread-spectrum signal used for digital broadcasts in the UK. It looks like noise, but technical documents still refer to it as having a carrier.
UWB is a solution to a problem which doesn't exist. Radio transceivers aren't that ridiculously expensive. Spread spectrum digital transmissions already exist in spectrum allocation and they work. We don't need another technology..
There is no "them-versus-us" with UWB. Their marketing department has been using this as a wedge to get press coverage. It's a load of crap. It's "common sense - versus - us" if anything. The FCC is quite rightly worried about this shoddy marketology.
The solution: use spread spectrum digital. Use COFDM. Use any number of already working band allocated technologies. Use 802.11. There's no need for UWB, and there's plenty of reasons why we don't want it. We should stop supporting this as a "geek" technology - you've all been had.
This sounds about right - that'll be the tolerance range of a typical hard disk. I remember from the empeg car player (I worked on that) that the temperature tolerance range could have been something like -20 to +70 if it weren't for the hard disks. There are some laptop drive manufacturers (can't remember which) making extended range drives now, so this could be better.
Then again, the Dension appears to use an LCD display, and those tend to handle temperature very poorly. You can get around the change in response time using a temperature sensor and programming in a different contrast, but you can only go so far. That's one of the reasons you'll see most car stereo units using either LEDs or a VFD display.
Am I completely mistaken, or is there no device with the following features:
Small form factor
No fan
10/100 Ethernet jack
Built-in amplifier
Plenty of analog (and digital) audio outputs
...that just listens to (unicast or broadcast) raw audio packets, sent over UDP, and converts them to analog, amplifies suitably, and emits them through analog outputs?
Actually yes. It's the Rio Receiver. I've set mine up to do this in the space of an hour before. It NFS boots (once you handle the UPnP/SSDP protocols) and all you have to do is get it to automatically run netcat or something and pipe it to/dev/dsp.
It's small, there's no fan in it, it's got ethernet, and it has a good quality built-in 10 watt amplifier. No digital output unfortunately.
First I wanna ask if you can get to a command line, can you modify it to encode Vorbis -- but then really why is this thing not cheaper than a computer you could build or purchase to do the same work? Not worth having or hacking.
Vorbis is currently implemented in floating point. The Rio Central has a StrongARM cpu inside, which hasn't got floating point support in hardware. Most other embedded devices have a similar story - floating point just isn't useful enough for the cost/power, and you can do everything without it just as efficiently and accurately.
So until somebody writes a free integer-only implementation of Vorbis, it's not going to appear in the vast majority of embedded devices.
XScale is *not* StrongARM, StrongARM is *not* ARM. So, calling this the fastest ARM PDA in the world is *incorrect* !
While the core is very different to current "ARM" cores, the instruction set and patents are licensed from ARM. It runs ARM instructions natively. Saying it's not an ARM is like saying an Athlon isn't an x86 processor.
It's basically an ARM9 core with the pipeline extended a bit and a DSP MAC unit bolted on the side. This equates to slightly faster than StrongARM speeds (per MHz) on most code, and maybe double on DSP.
Slashdot Mirror
Well there's three breakages already:
Secondly, in the real world IE won the browser wars, live with it. The end users voted with their mice.
I think that at least one justice system has found this to be untrue - users didn't vote with their mouse, it was won by illegal means. I mostly agree with that ruling. The world is more than just Windows and IE - that's what a proper platform independent protocol is supposed to be all about.
NAT is a hack. It also makes a mess of transparency and isn't 100% in the minority of cases. However, the minority of cases usually break completely. Even things like Quake broke originally until the protocol was modified and people put in special handling in their NAT stuff.
But NAT isn't a fair analogy at all. People use NAT on their home networks, office networks, and other small LANs. Or simply as a poor man's firewall. We're not asking VeriSign (or a local cache) for information on how we should NAT. It's a local hack with the locals completely understanding that it's in there. VeriSign's DNS hack has global effect and can't be turned off.
Unless, of course, you filter the response of "198.41.1.35" (what they return) to mean "host not found". But that would be a hack to fix another hack... which is usually how these poorly thought out "fixes" end up...
Here's an analogy: let's say you try to implement a method to display a pop-up search window when an executable file is not found. The obvious and clean way to do that is at the application level. When the application gets "file not found" from the filesystem, it arranges to pop up a search window. You'd only resort to alternate means if you can't modify existing applications.
Alternatively, you could implement a hideous hack where the file system instead opens a default executable. The application then never knows that the file wasn't found and executes it. It's achieved the same end, but it'll have a lot of side-effects. For a start, the application may not have wanted to execute it. It might even be trying to detect whether it exists. Other applications may not be expecting that behaviour and it'll break them. Another operating system may have that file system remotely accessed and end up running a non-native executable when it was looking for a native one. And years later, developers will still be working around this messed up behaviour because hacks are hard to get rid of once they are deployed at large.
DNS is not supposed to be a "lookup service for http transfers". Assuming that every lookup will be because of web browsing (by IE no less) is stupid. It's not even a good hack. As someone else who has replied to this article has pointed out it may not even cover the majority users. What about all those email servers bouncing email all over the place? What about all the peer-to-peer users? VeriSign would end up getting an enormous amount of non-web related connections hitting their "default IP".
VeriSign may be trying to get something out the door, but they could at least have implemented one of the preliminary specs (like simple UTF-8 encoding or mangling). Not a hack which only works for http transfers initiated specifically by IE, which breaks every other protocol and every other application.
It's actually another ARM7TDMI complete with its own unified cache, and shares internal SRAM.
And consider also that the iPod also has to maintain a UI during playback.
But Vorbis (Tremor) has roughly the same processing requirements as MP3 playback, so whatever difficulties there were before would be the same.
Presumably enough to at least do MP3. Vorbis (with the Tremor decoder) takes roughly the same amount of MIPS.
Perhaps you're not understanding that this isn't a "hardware mp3 decoder" chip - it's a general purpose CPU with approximately the processing power of an Intel 486 66-100MHz (depending on what you're doing). Provided the codec you want isn't too MIPS (or memory) hungry, you could software upgrade to support it.
There's no point-by-point comparisons I can find, but I'm very familiar with both. The main improvements on the XScale are:
However, there's a few things that aren't as fast, but can be mostly worked around by the compiler, or hand coded:
The result is that if your compiler groks XScale and you recode all the critical hand coded assembler, you'll get more than just the clock speed increase. If you run "legacy" code you'll most likely get a speed decrease vs the ratio of clock speeds, unless you happen to be stupidly heavy on multiplies and branches.
Aside from all that, it's got a lot of extra peripherals which are handy for embedded devices. It's quite likely I'll be working on an XScale platform soon, and I'm rather looking forward to it.
Intel's own marketing of MMX is inconsistent. In any case, XScale doesn't have what Intel refer to as "MMX" - but I thought I'd answer what the parent poster most likely meant.
The "Multimedia extensions" on the XScale come in two forms: the ARM-9e extensions and their own 40 bit multiply-accumulator coprocessor. It'd be nice to see the ARM-9e extensions in gcc as other processors would also benefit - not just XScale. This would be fairly easy to generate code for as you can "simply" replace two adds/multiplies with a single one in many cases.
The coprocessor is another matter and needs a lot of work from the compiler to get any speed increase out of its use. Last I looked at the processor documentation, I didn't see much advantage to using the coprocessor at all, even when hand coding assembler - the ARM-9e extensions give you pretty much the same speed increase anyway.
I'm not sure if it'll manage 100m, and you may have to play about with the wiring at both ends so there's as little as possible in the way, but it might do the trick. Besides, it's pretty inexpensive to try out. I've played about with PNA on relatively complex networks and the obstacle is usually the number of splitters/connections and not the distance travelled. I've never tried it as far as 100m, though :)
It sounds odd to me that you can't just pull some CAT5 through where the existing phone lines are. Or, replace a phone line with a CAT5 and use an unused pair for the phone line it replaced. I think 100m is around the maximum that ethernet will go down CAT5.
If cost is no object, you could peg up a GPRS link using a mobile phone :)
Me, I'd try PNA, seeing as that needs no extra messing about with cables. If that fails you seriously need to think about dragging CAT5 through where you've already got your phone lines installed. You might even be able to get ethernet down the phone cabling - I believe (UK) phone cable is still twisted pair, just not screened (or is it the other way around?). But I don't know enough about the issues there to comment more.
Any compiler worth its salt will see "i >= 0" and will give a warning "Range comparison is always true". As a bonus, if you do allow unsigned types, "i Unsigned types also improve performance on most processors. Division by a power of 2 is just a shift if it's unsigned. With signed numbers it's a shift, compare and conditional add. This optimisation cannot be determined at compile time unless you define the type as unsigned.
The only architecture I can think of where unsigned types are slower is Motorola 56k, which has so many other things wrong with it that it's not surprising. It's certainly (significantly) faster to use unsigned where possible on all non-DSP-oriented processors I can think of (x86, ARM, PPC, 68k, PIC, 6502...)
My thumb also rests naturally on 'n'. For the '.' on 'up.', I basically pivot my thumb on to '.' without moving my hand at all. It's much like ascending a scale on the piano - you play a few notes upward then "tuck" your thumb under for the next note so you can pivot your whole hand over to the next set. In this case I'm finishing a word so it's just a handy "free thumb" to use which doesn't require me moving my hand at all. I can stretch my hands to fairly ridiculous amounts, though, so I don't know how other people's mileage may vary :)
If all English words were made up of random letters, and had uniform occurance, this would be obvious. But because some words are vastly more common than others, and have a lot of similarity, this isn't so obvious. As you say, Dvorak promotes some runs like th, sh, wh - so why not extend to promote runs longer than two? You don't need to restrict to adjacent keys - so long as there's a different finger near the next key it'll be nearly as fast. However, my argument regretably lacks any data to back it up - much like yours does.
I might agree about the natural position of the fingers (though I suspect the natural position is actually somewhere in-between asdf and awef). But the idea that each finger can be on its own row is just wrong for normal hands. Ask some normal people to try it, and they'll tell you.
I see what you mean about it being somewhere in between. Perhaps I shouldn't have been quite so wide-sweeping with "one finger per row" statement. Some combinations are obviously ridiculous and would likely cause injury to yourself and the nearest 3 people. Other combinations aren't difficult and probably strain less than moving all of your fingers at once.
In general, my style tends towards "smoothing out" the stretching of fingers and movement of the wrists by predicting the required positions of each hand and moving progressively towards an optimum position for it. I agree that this is unusual, but I think that most people could learn this given time.
Where did these assumptions come from? I've got about 15 years of piano playing under my belt, and I find the standard "touch typing" rules very strange choices indeed. I type in a pretty free-form style at about 150wpm, depending on coffee. So, I'll disprove these assumptions one by one:
Not to discourage trying to find new keyboard layouts too much, but it's best to start really from scratch and question the basis of all the original assumptions. The rules need to include:
My theory about carpal tunnel and other typing related injuries is that "touch typing" is actually to blame. It encourages stiffening of the wrists and hands, discourages stretching, and generally leaves your hands as weak as they were before you started typing.
My advice to anyone that uses classical "touch typing" is to learn to the point of about 40wpm, and switch to improvisation. My advice to anyone wanting to switch to Dvorak for speed, or to reduce strain: it's ultimately limited by the speed of one-key-per-hand switching which is about 120wpm. From my experience with both, you're better off sticking with qwerty and going free-style.
It's usually pretty hard to thrash a code cache to the point of it being the bottleneck. You pretty much have to deliberately write code to do that. For reference, an Athlon has a 64KB code cache, and that's running at a far higher speed than both of these ARM processors. Your figure of 50-100 million ops/second assumes an unreasonable 100% instruction cache miss rate. You'd have to have a program totally devoid of loops to achieve that. At a still unreasonable hit rate of 95% you'd still get 96% ((95*400+5*100)/40000) of full performance.
My guess why the real world performance is so bad is probably Microsoft's lack of optimization specific to the processor. There's a few trade-offs Intel have made to get the clock higher, including:
I certainly wouldn't expect to be able to take code targetted for StrongARM and see all of the performance increase that 200->400 would indicate. I can imagine hand coding assembler to work around the latencies and getting near to 100% performance. It's not that hard for a modern compiler to work this out either - a current day x86 is far more difficult to target than an X-Scale.
You mean like lawyers do with... the law? The truth (and I mean that quite literally) is that every tiny little plausible interpretion of the law is exploited when it's to somebody's advantage. Intent doesn't matter, application is blind in the hands of expensive lawyers or large corporations. See Scientologists for a prime example. It does actually happen.
Banning direct links obviously doesn't work, which is why you say it's "reasonable" to also ban indirect links of any length. So option 2 is obviously out. That leaves us with:
There are many examples, papers, discussions etc on how most web pages are indirectly linked to another. Following your own logical progression, it would therefore be "perfectly reasonable" for a ban to include the entire web. Obviously that would be silly. Which leaves us with the remaining option:
It's as simple as that. This is why law is in general really twisted and complicated - it gets far too wide reaching otherwise. Sounds to me like this judge hasn't quite grasped the consequences that result from this. Or the logic, for that matter. IANAL, blah.
They are decent processors - you can do MP3/WMA/Whatever without an FPU. Hell, you can play Quake on them at a reasonable speed. Same goes for Vorbis - it "just" needs an integer implementation, which is rather a large task that nobody in the public domain wants to take on, and no business wants to spend development time on.
Sorry, didn't mean to have that impression come across. The main problem is that it's going to take a long time to rewrite all of the algorithms for integer. It's a shame really, because it would have taken just about as long to write it in integer in the first place. Floating point isn't the magic bullet everyone makes it out to be - it doesn't eliminate truncation and it certainly doesn't eliminate word size issues.
Actually, I find DSP code written in integer easier to understand because you can see exactly where the author is taking care of those issues much more clearly. In floating point it's all a bit magic, and in most cases they just didn't realise what's actually going on.
There's integer decoders for MP3 and WMA (and all sort of other codecs), so I agree there's no particular reason Vorbis couldn't be either. In fact, there are integer implementation of Vorbis - the trouble is Xiph want to sell them. Fair enough, but hardly anyone's going to buy it, and you've got to weigh that against the market penetration you'd get if it were free. Maybe they've got it right, but it still annoys me that, for example, I couldn't add Vorbis to an empeg car player because integer Vorbis isn't free, and I don't have the spare time to write an integer version.
For example, I am not aware of any flash portable pocket player that has an FPU. That's because it's entirely possible to do MP3/WMA in integer. Nobody is going to fit an expensive and battery draining processor into their product just to support an extreme minority codec.
By using floating point for the algorithms, libvorbis is ruled out from nearly all embedded devices. At the moment it pretty much only runs (in real time) on PC/Mac systems.
I don't see any of the UWB promoters giving me enough information to support their claims. Very well, I'll fill in some of the blanks I admittedly left:
1. What is COFDM?
Coded orthogonal frequency division multiplex. It splits the information on many (typically thousands) or carriers. Basically you take a bunch of bits to form a symbol. FFT that (kind of) to get the amplitude of each carrier, and transmit. To receive: modulate down to baseband, inverse FFT. Well, actually that's OFDM. COFDM modifies the output bits before modulation so the carriers are less susceptible to multipath. See this paper on OFDM/COFDM
2. What kind of bandwidth, range can I get out of it?
Pretty much any, depending on how you pick the number of carriers, bandwidth, signal strength, and carrier coding. In digital audio/video broadcast, it goes 2 - 68km, at 5 - 32mbit, using just 8MHz of bandwidth. See this paper
3. Why isn't the industry pushing COFDM?
They don't need to. Digital Video and Digital Audio broadcast in the UK and (I think) some of Europe already uses COFDM. 802.11a already uses OFDM (it's only short range so you don't need the multipath protection). Everyone (except the US digital broadcast people, much to their disadvantage) already recognises it as "the thing to use".
4. How expensive is it to integrate COFDM onto a small device, such as a PDA?
Depends on the bandwidth and whether you offload all of the modulation into hardware or some in software. You've probably seen articles about Microsoft wanting to push processing of wireless lans into software (article). I haven't got any figures and I probably wouldn't be able to find any without NDAs. My ball-park guess would be from no milliwatts for 10kbit+, to 100mW+ for 1mbit+.
5. What's the spacial capacity?
Depends on choice of number of carriers, carrier modulation scheme, error correction etc. There's probably theoretical limits, but it's very versatile.
6. How much power does it use?
Ditto. It's not very suitable for very low power (milliwatt) devices - you're better off with bluetooth then. You can get lower power by reducing the number of carriers, error correction, etc which also lowers your data rate. I have no idea which uses less power. UWB will certainly use up a fair bit of power with its high speed pulse train. Still, you'd probably use something simpler like bluetooth in really low power low data rate devices anyway.
As far as spatial capacity goes, it's not at all an indicator of whether one technology is better than another. It says only whether you can get that data rate at the maximum distance you require. So for short range usage, all of your examples will work. What's important then is power vs data rate. I can't say any more as to which is more suitable because I don't have a figure for ODFM, PSK and all the other reasonable existing technologies, nor do I have one for UWB. It would be hard to give a definite figure anyway - it would depend on assuming a particular implementation is optimal.
The solution: use spread spectrum digital. Use COFDM. Use any number of already working band allocated technologies. Use 802.11. There's no need for UWB, and there's plenty of reasons why we don't want it. We should stop supporting this as a "geek" technology - you've all been had.
This sounds about right - that'll be the tolerance range of a typical hard disk. I remember from the empeg car player (I worked on that) that the temperature tolerance range could have been something like -20 to +70 if it weren't for the hard disks. There are some laptop drive manufacturers (can't remember which) making extended range drives now, so this could be better.
Then again, the Dension appears to use an LCD display, and those tend to handle temperature very poorly. You can get around the change in response time using a temperature sensor and programming in a different contrast, but you can only go so far. That's one of the reasons you'll see most car stereo units using either LEDs or a VFD display.
Actually yes. It's the Rio Receiver. I've set mine up to do this in the space of an hour before. It NFS boots (once you handle the UPnP/SSDP protocols) and all you have to do is get it to automatically run netcat or something and pipe it to /dev/dsp.
It's small, there's no fan in it, it's got ethernet, and it has a good quality built-in 10 watt amplifier. No digital output unfortunately.
Vorbis is currently implemented in floating point. The Rio Central has a StrongARM cpu inside, which hasn't got floating point support in hardware. Most other embedded devices have a similar story - floating point just isn't useful enough for the cost/power, and you can do everything without it just as efficiently and accurately.
So until somebody writes a free integer-only implementation of Vorbis, it's not going to appear in the vast majority of embedded devices.
While the core is very different to current "ARM" cores, the instruction set and patents are licensed from ARM. It runs ARM instructions natively. Saying it's not an ARM is like saying an Athlon isn't an x86 processor.
It's basically an ARM9 core with the pipeline extended a bit and a DSP MAC unit bolted on the side. This equates to slightly faster than StrongARM speeds (per MHz) on most code, and maybe double on DSP.