Sun machines on the other hand don't excute each thread all that fast in comparison, but my God! Have you seen that sucker when you ramp up the number of processes/threads?!
Yes, I have. They still fall behind. On the other hand the hardware almost never fails, is a lot simpler to "fix" remotly (tell it to boot off of another drive, or boot of of CD and reload the OS, or just power down and back up). They are also much simpler to get in the same config for more then 3 months in a row.
Even real fixing is frequently simpler. SCA drives are wonderful (and yes, you can get SCA PCs, but once you configure a SCA PC the price tends to go above Suns!)
That is why we use them for servers a lot. A lot lot. A very very lot. Even with the CPU gap.
I'm with ya there. I had to reread their page a few times before I let myself believe. I was waiting to see *disk/cpu not included or something.
Well it is "FrameBuffer, Audio, SCSI" not included. Not that FrameBuffer has any value for a rackmount server, Audio has almost none, and SCSI, well, that would be nice, but I guess they have to cut the cost some how. NEBS would be nice as well, but again...
The drawback is no PCI slot. So there are a lot of things you can't use it for. Beyond memory and disk space there is basically no expansion at all. No gigabit ethernet. No RAID. None of that. A pity. But there are other Netras.
What's the chance of me (or someone) doing something like this on their own (ie to create something like a TiVo or ReplayTV or whatever they call them boxes that record and playback TV on a hard disk)?
There are basically three hard things the TiVo (and I hope Nokia's box) does:
Real-time MPEG2 encode (except the DirecTiVo) -- this is "hard" as in interfacing to a chip that does it, or "hard" needing a whole lot more CPU then you'll get cheep.
Drool-proof interface. This really is a hard thing to do. And TiVo does a quite nice job. Even after using it for a week you'll find little corners where they did a nice job (and places they could have done more).
Streaming one (or two on the DirecTiVo -- someday) encoded video to disk while reading and decoding another stream AND making a PPP connectiong and transfering data, or indexing that data without the video getting choppy, or losing input sync. In TiVo's case with very little RAM (16M?)
If you did this as a home project you can ditch the drool-proof interface. You can ditch the "very little RAM", and you can apply a lot more CPU, or maybe you can find a MPEG codec chip with actual docs. It is still a lot of work. Oh, and for a homebrew version you will need a source of TV Guide info.
It is a lot of work. Doable, but still a lot of work.
As far as hardware in the TiVo, it has a tiny bit of RAM (16M? 8M?), a MPEG codec, and a fairly slow PowerPC, like 50Mhz (the MPEG codec does most of the lifting), and fast, but not "AV" IDE drives. They sell for $399 new. If they had an ethernet it would be a no-brainer to get one of them and hack it (you can get to the Bash prompt easy, all you need is a cable, you don't even need to open the case!). A 30G disk is probably a good size.
You won't save money doing it yourself. You may end up with a better toy (at least better for your needs). Hell you may end up with a viable product. You may have fun. You will not save time. Or you could end up with another pile of hardware you arn't using, and another project abandonded before completion. I bought the TiVo, but I have a few other things I'm working on just now...
Really!? Cool. There goes my last reason *not* to get the preview release. Thanks for letting that be known.
Thanks, but I read it first on slashdot:-)
Eh? What would you prefer? A BSD kernel?
Yes. A modern BSD kernel rather then the Mach microkernel with the monolithic BSD single server on top of it. Which is a pretty damm old BSD kernel (older then FreeBSD/NetBSD/OpenBSD and BSD/OS -- not older then the kernels, but older then them!). It is nice that there is a new layer of things to let the FreeBSD device drivers to slip in without too much trubble though.
A modern Linux kernel would probbably be better then the mach kernel, but I don't have enough Linux experiance to say for sure.
It's not that there is anything stunningly wrong with Mach, just that it has seen way less work over the last 8 years then any of the BSDs (and they started at about the same place), or Linux (which Mach started out ahead of).
That is, of corse, assuming that the WINE hooks, or SCO hooks, or other other OS hooks are enough to cram Classic into a BSD or Linux.
Personally, I wish that OS X was more like NeXTStep, and less like OS 9. I can see why they would want to make the transition easy, but jesus, Mac OS has had so many ideas piled on top of each other for the past 16 years that I would like to see an almost pure NeXT desktop on my Mac. Pure, simple, and uncluttered NeXT-ness.
If you ditched the NextStep menus and went with Mac style ones that would be pretty decent. But this is a lot better for getting older Mac users not to be intensly upset about OSX.
I like the Dock. It makes it far easier than the classic application switcher to quickly see what you're running (all you need is a quick glance), and is also better than the Windows task bar, as the Dock icons take up less space than the text names in Windows.
The dock isn't bad, but I miss the quick-bar, and I only used OS9 for a week! (Prior to that I has used whatever MacOS came before the first color Mac!).
That's my rant. Mac OS X is something that Mac fans have been waiting for for the better part of 5 years.
I've been waiting for someone to do a "drool proof Unix" for a lot longer then five years. I'm supprised it is Apple, and pleased too. (I can't count NeXT because I never had admin on one, and can't say how drool proof that part was -- at least if it was actually first I'm only delaying it's credit to recognise it now as OSX...)
Erhm, you are forgetting that Mac OS X PB is time limited (rumoured to stop working May 15, 2001). Oh, and to run older MacOS apps you need MacOS 9 too. Sure, OSX will run fine on it's own, but there are not may apps out there, and porting is a little finnicky still. Mac OS X is taking a *lot* from older operating systems. After installing the developer tools it struck me that it's a *LOT* like NeXTSTEP/Rhapsody, even the ProjectBuilder.app, the UI designer, Core Foundation libraries and the FreeBSD kernel.
Where to start?
OSX PB is time limited, but you get to refund it's price vs. the OSX release price. Not the worlds best deal, but not a total rip off.
All the older apps I rand under OSX ran just fine (it started up "Classic" which is almost certonally a modifyed OS 9). In fact other people have reported running 68000 programs like MacDraw 0.8 under Classic. Oh, and for anyone who has never seen it run to start an old app "under Classic" you put the mouse over it and click twice (or click on a document associated with it), if "Classic" isn't running it starts automatically (but slowly), then your old app starts, and you are thrown into a world of the past (the old nice task switcher is back and all). You can click on your new apps to get back. Not the best thing in the world, but pretty easy.
I have seen an app that didn't work right under Classic. Apple's own iMovie got a bad aspect ratio and was gennerally unplesent. I hope it is fixed for the release (in twoish months). Hell I hope there is a new public beta next week and iMovie works under it!
Of corse it takes a lot from old systems. It is NeXT after all. And better off for it. mostly. It is a shame they are using the Mach kernel. The network stack needs work. I have to down/up the ethernet every once in a while to keep it running. Sometimes I have to flush the arp cache. I hope that gets fixed in the release too.
Still under OS9 the mac crashed three times or more a day. Under OSX in three weeks I have had one panic. A few application crashes (actually a lot if you count some of the repetable ones I tracked down, but I was looking for the source of the crash). Zero hangs. Zero failure to un-sleep (it is on a laptop). Two or three "system getting slower and slower because the window system and/or finder looks like it is leaking memory" where logging out and in again made things "all better".
Not the kind of quality I would hope for in a Unix desktop, but far far far better then the old Mac OS, or Windows. And I can allways hope it gets better in the release.
Okay, name 10 people in your direct vicinity that *use* Mac OS X PB _right_ _now_. You can't huh? Well, *that*'s how mainstream it is...
Name 10 people in your direct vicinity that use Windows wissler right now. Tell me that hunk of crap won't be mainstream within six months of release.
I fully expect Apple to be the biggest Unix seller by volume (not dollars!) when OSX gets bundled with all new Macs ("this summer"). Is that mainstream? Well Apple has a pretty low desktop share, and OSX will take a while to help it. It'll sure be mainstream for video editing systems though, and people who shoot comercials digitally, and some other markets. It'll sure deserve the mainstream more then Windows. And until Linux/FreeBSD/whatever gets a nice candy coated shell that my mom can use, it'll deserve the mainstream more then the other Unix systems as well.
LOL, you are either being insanely sarcastic or have little experience shopping for a car!
Honda didn't show me a VW. Honda didn't try to make my wife look at an accord rather then a Civic. They did try to convince her to buy a 4 door rather then two door, and the "wrong" color. But not very hard. (they had no two doors in the lot in the trim line she wanted, and they only had the wring color too). [of corse I'm guilty of making my wife look at things other then the Honda Civic]
Volvo didn't try to sell me a VW or Audi even though they were in the same dealership (in the same big room even). They didn't even point me at a diffrent color or trim line. Then again I actually wanted something off the lot.
Of corse the last time I bought anything (modestly costly) at a retail chain they questioned my choice. I bought a DISH reciever to replace my existing one, and they wanted to sell me DirectTV. I wanted the Phillips 60hr TiVo and they wanted to sell me a Sony 30 (or the Sony + DirectTV 35).
So basically empathy for Ender is the prime motivation for liking this book. Doesn't that bother you? As a community we bestow accalodes on this book because we empathize. A community that prides itself on vetting the weak code and on a rabid tradition of intellectual inquiry and debate, gives this book a free pass because it sounds like us.
What's so amazing? That we give emotion a role in selecting entertainment while we avoid it in writing code? Maybe because entertainment is in large part emotion, and code is only in tiny part emotion?
To me it wan't the best book in the world. It felt that way when I was 15 and reading it the first time. It doesn't make my personal top 100 anymore, but it still gets to be "worth the read".
I don't think realism is really that big of a deal, plausability, story, and ideas are far more important.
In SF plausability isn't even that big of a deal as long as there is internal consistancy. If you read Asmov's robot tales they arn't very plauable (at least they don't seem so plusable anymore). But they are internally consistant.
I agree that early Niven is way better than late Niven, but that's not to say that early Niven is good. Just bearable. Ringworld had no plot, it was just a series of "wonders". Some of his short stories are good, though.
I agree the tipical Niven style has no charactor devlopment (unless mind control or eating a plant counts). That makes his novels hard for some people to enjoy, while his short stories remain great.
However I'm not quite as negitave, I like his novels as well, just not as much as his short stories. I like his older work more then his newer, but I'm not sure how much of that is him, or me.
The one exception? Destinies Road. Decent plot and charactor devlopment, and decent wonders as well:-) It was a late 90s book, and IMHO his best novel.
Seems they've dropped their line about multiprocessors, since the only model that ships with them is the 533 MHz model. I can't seem to find any information on if they include an empty socket or not for the other configurations...
As far as I could tell from the two hour long quicktime they all have slots for a second CPU, but jobs didn't think supply would match demand on the faster CPUs and they are not offering the second CPU except thruough channel partners (read "very expensave").
He also seemed to say the G4 PB wasn't actually available until the end of the month. Which sucks because I want to return my G3 one right now for the G4:-)
Of corse the G4 one also says it won't run OSX-PB2, so I may have to wait two months for the real relase...
Aren't you thinking of MPEG2 _decoding_? Ultra 1s ran at, what, 167MHz, something like that? Ultra 2s maxed out at something like 300MHz. I seriously doubt a 300MHz UltraSPARC II is about 4X faster than a Motorola "G4".
I think it is encode speed, but I can't find my "VIS Propaganda Manual" anywhere. I'm pretty sure the pixel-distance instruction that does the work of about 40 other instructions in a single cycle and most of the work a macro block needs made it a whole whole whole lot faster.
I'll look for the thing when I get back to work, it may be on my bookshelf there. If it wern't for the fact that I know the pixel distance instruction is useless to a decoder I would doubt my memory.
To Job's credit Sun did such a stunningly poor job of selling that feature, that iDVD on the Mac years later still looks stunning. Even to me:-)
Steve Jobs claims that the MPEG-2 (encoding) CODEC that iDVD and DVD Studio Pro use is "much faster
than any other". He claims that most other software encoders for MPEG-2 run at about a 20:1 ratio, while
the CODEC Apple has can encode at about a 2:1 ratio on a G4... that is, 30 minutes of video can be encoded
into MPEG-2 format in about 60 minutes.
The Sun ULTRA2 (or maybe ULTRA1?) can do two NTSC size MPEG2 streams at once using the "VIS extensions" (which are a bit like AltiVec, SSE/SSE2/3DNow/all the other SIMD extensions). I don't know if that includes an audio track, or disk I/O. The ULTRA2 is many years old and no longer sold by Sun. I assume the newer systems can do a way better job.
Note: the Ultra2 may not be all that fast, but I think the PDIST (or PDIFF?) instruction is extreamly MPEG2-codec-centric and helps make up a lot of ground in this benchmark.
tell me about it... i do tech support for dsl, and it doesn't help that there's no damned _ping_ that comes with
the unit. amazing how a machine built for networking since the beginning has none of the tools you'd expect.
Eh? OSX (at least PB2) has ping, it also has ssh, and apparently a telnet (I've never used it). It also has traceroute. Oh, and vi (so it isn't a network tool, but it is funny to see it on a Mac...).
Unfortunitly it also seems to have a lame DHCP client (how do you get it to ask for a new lease? Down the interface, delete all addresses, and bring it up; what do you do if networking vanishes for no reason? Try flushing the ARP cache).
The system is never really taxed and
AFAIK has yet to crash on her.
Really? Does she use the web at all? OS9's MSIE crashed about twice a day for me, and Netscape made the system plenty unresponsave. Oddly enough OSX's MSIE crashes way way less offen (once in the week I have had it), which is kinda odd given that it is a beta of a product for a beta OS that it is more stable then their release product for a release OS.
I do hope Apple gets people to go from OS9 to OSX. If Apple can finish up device support for OSX and get the finder a little more usable I don't see much advantage to sticking with OS9.
Find me a $400 Wintel box that comes with USB, Firewire, 10/100 Ethernet, a monitor, 3D video, and gets
anywhere close to MIPS. Can't do it? Didn't think so.
I think you can hit $500 with a lame monitor and ditching the FireWire. I havn't ever used the FireWire on my Mac (my digital camera is USB, and even if I had FireWire devices OSX-PB2 doesn't have support, and I'm running OSX-PB2....).
Don't forget that with the iMac you will be replacing the mouse, and if you have carpal tunnel the keybord (not a huge deal, but still...).
The big reason I dislike the iMac is the built-in monitor. The monitor is one of the few upgrade durable parts of a system. Get a good one an it isn't a big deal to keep it for a decade. The iMac takes that away.
On the other hand, as another poster said their notebooks are pretty good for the money.
NASA - Symphonies Of The Planets, Volume 2 at least is the voyeger recordings. Cdnow doesn't have it, but half.com does (for les then $5 for many of them).
I've also only been working now for just over 18 months; I don't know if that counts as "just starting out", though.
I didn't really have much to save until about 3 years after i left collage. I didn't really start doing it until about five.
Oh no, wait, then I'll have to think about getting a decent pension, and some life insurance.
How does pension work in the UK? Here we pay social security, which will probbably not give us a dime when we retire. We can pay into a few tax exempt savings plans that can pay out tax free when we retire (or with taxes before that, or can be borrowed against for some things) and that normally goes through an employer, sometimes they throw in a little, or do some matching.
Unless there is a big tax break, you may just want to start by having a money market account or the like, it won't grow as fast in the long run, but it will be avilable for more kinds of emergencies.
Better yet, hire a finincal planner (not now, when you have money to save). It was probably the smartest money I ever spent.
Do I regret it? Not for a second.
I hear you. I don't regret getting mairred either, even though it pretty much made me give up consulting as my main income source (which cut my pay by 70%, and made me drop out of collage).
With everyone hacking their Dreamcasts to run BSD, and noone buying games, and Sega losing money on each piece of hardware sold, won't this drive Sega into further money problems?
Sure, if enough prople did it. But I expect most people buying a Dreamcast will buy some games even if they want to hack a Unix onto it. Plus if enough people were hacking Unix onto it to be a problem, Sega could "just" build the system profit into the Ethernet (roumored to be on sale RSN). Unix geeks can't resist an ethernet, can they?:-)
Most video game systems break even when two games are bought for it. I have nine (and and 4 Sega controler purchases, and two VMUs), so I can handle at least 3.5 free loaders. Who wants to sign up?
Seriously Sega has a much smaller problem here then iOpener, or web-runner because even if we hack the box, they still provide a service. I mean it would be cool to play nethack ont he dreamcast on my TV, but it isn't going to replace Sega Bass Fishing now is it?
My understanding was that the Dreamcast had a proprietary "GD-ROM" drive that has a capacity of 1Mb or so I asked Is this being used a the boot device for NetBSD?
It does, but only because the Toshiba (or Yamaha?) play to be the first sellers of 1G CD-RW systems failed. Mosty because nobody wanted them. Many can still write them! They can't be read on normal CD-ROMs, so people wern't intrested. It fizzled, and then later Sega licenced it.
The Dreamcast can also read normal CDs, otherwise we wouldn't have any music:-)
Your employer owes you nothing. You owe them nothing. Their gratitude to you is as nonexistant as your gratitude to them.
In most states they owe you two weeks pay. I think they owe you a bit of warning (say half an hour), but there is no law that I know of that says that.
Every programmer worth their salt makes enough to save some on the side - if you don't have enough money saved up to last you six months of lean living in the event of a layoff, either your expenses are too high, or you're a moron. Either way, you screwed yourself.
Nah, people just starting out may not make enough (I know I didn't). People with a family may not.
Pink slips happen, and anyone with a brain can see it coming by at least a month.
Being fired? Yeah, you should be able to see that well in advance. Getting layed off? Well if hte compony isn't public, there may be scant little chance that you know in advance.
If you can afford to save, it's a good idea. You may need it, could be lay offs, could be a family emergency, could be anything. But not everyine can afford to do it.
When I worked for MP Games in 1992 (a small coin-op maker, once part of Microprose) the arcade monitors were pretty much not very impressave. The were standard NTSC monitors frequently pushed a bit beyond spec. They were chosen mostly baised on size, and price. Color rendition and sharpness and so on were not as important. I was given to understand that that was pretty much industry standard.
This is in sharp contrast to the controls where feel and durability was (mostly!) more important then price.
The color fidelity didn't get corrected for since diffrent batches would have diffrent shifts. The bleed of the screen was sort of taken into account, in that antialiasing wasn't really done except by assuming the monitor would do a bit of color bleed (which is why things like GL mame look a bit more like the originals then stright mame).
Sharper will probbably not look much better (colors will look nicer, but the graphics will look a little more pixelated).
Depending on the era of your machine, and the maker your milage may vary of corse. A few games probbably didn't use normal NTSC monitors, or use high quality ones. But in '92 it was not common, and before that I doubt it was common except for vector games.
Unfortunately, I don't have the paper anymore and it has been over a year since I read it. That recount is what I remember.
My guess is that the paper and Compaq have slightly diffrent definitions of SMT. I assume the paper chose one the author thought was intresting, or easy to evalulate, or easy to implment, or most constructave to evalulate, and Compaq chose one that would give good value for the design and transistor investment.
Given that very little existing software could use all-in-one-MMU-context SMT (multithreded programs only, and only CPU bound ones would take much advantage), and pretty much any CPU bound server workload (anything with more then one process) could take advantage of SMT with multiple MMU contexts.... of corse that assumes the implmentation cost isn't too horrific, but given that they picked it...
Anyway, if you do get another copy of the paper I would love to see it. Even if it doesn't exactly address Compaq's SMT, it sounds intresting. I can't find it with google, but maybe if you remember the title of the paper, or any authors other then Prof Berger?
The cores are actually able to execute in different contexts as well, not just within the same context as with SMT.
Who says the threads all need to be from the same context? I asked a compaq guy about that 14 months ago and he said they cold be from diffrent VM contexts, and (and this was a supprise to me) load/stores in diffrent MMU contexts can be done in one cycle.
I don't recall if he was on the EV8 team, but he was in their CPU design department (his focus was on heat though).
That means you could easily pay $20,000 for a 16K ROM, no kidding. Rad-hard 74xx logic costs at least $200/chip. The RAM is not rad-hard, an active "scrubbing" routine repairs single-bit errors before they grow too large to correct.
Do you mean rad-hard as in "can take a rad hit, and then read back the old data later", or "read proper data durning a rad hit"?
If it just has to work OK after a rad hit a masked ROM is inharently rad hard (it isn't a set of fuses that can be blown, it is a set of WIRES). Masked ROMs use to be quite cheep in reasonable quantity (100+). They also use to have wonderful density and speed. However MROM has lost a lot of research funds as flash has basicly eaten 90% if it's market (and even more severly into EEPROM). I think MROM is not only used when cost is a huge issue, and changes are not beleved to be needed (like maybe by Handspring...). You may have to set the way-back machine to about 1994 for memory size, but that is still a lot better then 16Kbytes!
As long as you want masked ROMs smaller then about 16Mbits (2Mbytes) they should be pretty cheep. Like cheep enough to go into Super Nintendo cartrages (or at least N64 -- I think SNES made do with far far far smaler cartrages)
Thats just it though- I did not mean to use TCP over ATM, I was meaning to use ATM's reliable transport features so TCP would be redundant.
Fine, but reliable ATM has ACKs, so a ATM with 1024 byte packets would have 1024 byte ACKs. And would not have TCP ACK compression (which can send half as many ACKs, or less, if traffic is moving fast enough), and will miss many of the other fine TCP features.
My only dirrect experiance with a reliable ATM product was wholey negitave. It managed to carry about 2Mbits over a 16Mbit pipe. It was a disaster. Replacment with Frame Relay was a wonderful success, carrying almost 16Mbits within two hours of being turned up. Part of this was assuradly the hand-off media (but no more then 8Mbits loss could reasonable be attributed to that), and part was assuradly the poor hardware implmenting reliable ATM, but a large part was the poor reliable ATM itself, and the complexity which made it hard to have a good implmentation!
I know ATM was designed to carry voice phone traffic, but an ATM with 1024 byte headers would not be useful. Too much data would be in it. You can't buffer 1K byte (8K bits) of a 56Kbit voice stream without introducing audable latency. Existing 46 (or is it 36?) byte cells sometimes go unfilled in voice applications.
In other words a fixed 1024 byte ATM cell size will make ATM extreamly unwealdy. Far worse then existing ATM which is widly cratisized for throwing away ~33% of the banswidth.
I know that current ATM converts to electric signals to switch, what I meant was an optically switched ATMlike protocol would propagate at the speed of light. Signalling will still be far slower, but an established connection will be full speed.
Big deal. Optically switched IP would switch at the speed of light as well. Neither are likely to happen soon. The only thing that switches at the speed of light is the extreamly unflexable lambda switching, and that is all we are likely to have for quite some time.
reading about MPLS from here and here It looks basically like a way to do IP over X, where X is Frame relay or ATM. It cannot be simpler than them if it requires them to work.
It is a way to run IP over X, and I don't think it can run anything but IP. However X is a lot more then ATM or Frame Relay. It includes Packet over Sonet (which is basically a no-overhead no-service protocall), there is also a MPLS over PPP. I think there is a MPLS over ethernet as well. In practice there can be MPLS over anything. In reality it works better with things that can send either variable sized packets (with a large minimum size), or continous streams of data.
MPLS over ATM or Frame Relay is there more to get experaince with MPLS then to actually be used. You are right if you have allready payed for ATM or Frame Relay there seems to be little point in slapping MPLS onto of it before going for IP. MPLS was intended to be run very close to the wire, not on top of a complex protocall that does everything MPLS does and more. MPLS was a reaction to the loss of ATM and Frame Relay at higher speed interfaces.
I had no hand in deigning MPLS, I was merely on the same floor as some of the people that did. But, I have talke to them a bit. (I have only slightly more to blame for PPP over Ethernet)
There is some small chance that if MPLS is wildly succesful, one might want to run it over ATM or Frame Relay just because MPLS links are simpler to mangage. However I think chances of that are slim. I don't expect MPLS to be signifigantly more managable then Frame Relay or ATM, dispite being designed in large part by those that will have to manage it!
About variable vs fixed sized packets: well that is one of the main tenets of ATM. When you have a fixed size packet you can make a whole lot of assumptions in your network stack, which can seriously speed up performance. The problem is picking a packet size which is small enough for all hosts to handle quickly, and large enough to move reduce overhead. I think something in the neighborhood of 1024 bytes would be appropriate.
1024 bytes will suck for carrying an IP packet that is just a TCP ACK (and about 30% of TCP traffic is dataless ACKs). It also sucks for carrying interactave voice traffic (i.e. phones). The duel sized ATM-varient actually has almost all the advantages of ATM at the hardware level. It is *almost* as easy to support two sizes as just one, and a far bit simpler then supporting true variable size packets.
You will notice I said something like ATM, not something that is ATM.
It was simpler to ignore "something like" then to guess how much like ATM you wanted.
MPLS seems to be an attempt to get IP over ATM. I dont think that will work- sounds like the worst of both worlds in terms of complexity. What I would advocate is something more along the lines of straight improved ATM.
It is really a stright forward attempt to get the advantages of IP over Frame Relay without all that complex Frame Relay stuff. And it is simpler then Frame Relay, and ATM, at least if you compair them fairly. At the packet level it is series of 16 bit tags followed by data (over ethernet this lives where the data normally lives, and there is a MPLS protocall number). Each MPLS switch pops off the first tag, and sends the packet out that interface. Simple enough to do cut through routing all in an ASIC without even a CAM involved. ATM needs a small CAM, or a large (but managable) lookup table. Same for Frame Relay. Both have extra fields to mostly ignore.
If you had an ethernet design in VHDL you could probbbly make a (non cut through) MPLS switch in less then 200 lines of VHDL, and definitly fewer gates then 802.1Q (or whatever the VLAN spec is); of corse it would be a MPLS that doesn't let anything else assign it's tags, but hay, what do you want for an hour's work?
All three have complex "call setup" schemes, and fallback schemes for dealing with link failure. The MPLS ones are several orders of magnitude simpler if you take statments like "use BGP to find a normal IP route, and do a trivial conversion to MPLS tags" at face value. Otherwise the MPLS ones are only somewhat less complex. ATM and Frame Relay have the notable advantage of being out there and tested for quite some time now. MPLS isn't over it's teething problems.
The biggest issue that MPLS haddn't fully grappled with as of the, um 1998 or early 1999 MPLS confrence was dealing with circuit failure. As far as I could tell they wanted something that delt faster then an ATM re-route, but without "waisting" half the bandwidth like a protect circuit, or a SONET ring. The big issue is if it takes 30 seconds while routing reconverges and they have to throw away a lambda of data, well, that is just a whole crap load of data to drop.
Oh, and of corse the "until there is a large scale deployment, nobody knows for sure it won't have nasty problems in a large scale deployment" problem. Of corse it's not like a faster ATM scheme wouldn't also have that problem. I mean the first UUNET ATM backbone had serious teething problems, and ATM switches should have been a well tested technology in 1993 (or was it '94?), right?
The advantage of such a system are essentially these two: low latency- in an established connection packets propagate at the speed of light, reliable transport - tcp style virtual circuits are the normal mode of communication rather than a datagram oriented method with a virtual circuit built on top of it.
ATM and Frame Relay don't give anywhere close to light speed switching. Lambda switching will/should do that, but it will be more closely related to MPLS then the other schemes!!!
A virtual circuit that doesn't gaurentee data integrety will still need something like TCP running on top of it. All known virtual circuit like systems that do the data integrety themselves are worse then TCP (they don't need too, something like delta-t might be better).
Explicit circuit switched networks were here for decades before IP became popular. It is just a whole lot simpler to use a packet switched system. The difficulty of making a large packet switched network is just the price we have to pay to make the network usable.
Granted my networking experence is mostly limited to IP, things you can run on top of IP, and things IP can run on top of. But I'm pretty damm sure of all the statments I've made.
Slashdot Mirror
Yes, I have. They still fall behind. On the other hand the hardware almost never fails, is a lot simpler to "fix" remotly (tell it to boot off of another drive, or boot of of CD and reload the OS, or just power down and back up). They are also much simpler to get in the same config for more then 3 months in a row.
Even real fixing is frequently simpler. SCA drives are wonderful (and yes, you can get SCA PCs, but once you configure a SCA PC the price tends to go above Suns!)
That is why we use them for servers a lot. A lot lot. A very very lot. Even with the CPU gap.
Well it is "FrameBuffer, Audio, SCSI" not included. Not that FrameBuffer has any value for a rackmount server, Audio has almost none, and SCSI, well, that would be nice, but I guess they have to cut the cost some how. NEBS would be nice as well, but again...
The drawback is no PCI slot. So there are a lot of things you can't use it for. Beyond memory and disk space there is basically no expansion at all. No gigabit ethernet. No RAID. None of that. A pity. But there are other Netras.
I hope BSD/OS runs on it :-)
There are basically three hard things the TiVo (and I hope Nokia's box) does:
If you did this as a home project you can ditch the drool-proof interface. You can ditch the "very little RAM", and you can apply a lot more CPU, or maybe you can find a MPEG codec chip with actual docs. It is still a lot of work. Oh, and for a homebrew version you will need a source of TV Guide info.
It is a lot of work. Doable, but still a lot of work.
As far as hardware in the TiVo, it has a tiny bit of RAM (16M? 8M?), a MPEG codec, and a fairly slow PowerPC, like 50Mhz (the MPEG codec does most of the lifting), and fast, but not "AV" IDE drives. They sell for $399 new. If they had an ethernet it would be a no-brainer to get one of them and hack it (you can get to the Bash prompt easy, all you need is a cable, you don't even need to open the case!). A 30G disk is probably a good size.
You won't save money doing it yourself. You may end up with a better toy (at least better for your needs). Hell you may end up with a viable product. You may have fun. You will not save time. Or you could end up with another pile of hardware you arn't using, and another project abandonded before completion. I bought the TiVo, but I have a few other things I'm working on just now...
Thanks, but I read it first on slashdot :-)
Yes. A modern BSD kernel rather then the Mach microkernel with the monolithic BSD single server on top of it. Which is a pretty damm old BSD kernel (older then FreeBSD/NetBSD/OpenBSD and BSD/OS -- not older then the kernels, but older then them!). It is nice that there is a new layer of things to let the FreeBSD device drivers to slip in without too much trubble though.
A modern Linux kernel would probbably be better then the mach kernel, but I don't have enough Linux experiance to say for sure.
It's not that there is anything stunningly wrong with Mach, just that it has seen way less work over the last 8 years then any of the BSDs (and they started at about the same place), or Linux (which Mach started out ahead of).
That is, of corse, assuming that the WINE hooks, or SCO hooks, or other other OS hooks are enough to cram Classic into a BSD or Linux.
If you ditched the NextStep menus and went with Mac style ones that would be pretty decent. But this is a lot better for getting older Mac users not to be intensly upset about OSX.
The dock isn't bad, but I miss the quick-bar, and I only used OS9 for a week! (Prior to that I has used whatever MacOS came before the first color Mac!).
I've been waiting for someone to do a "drool proof Unix" for a lot longer then five years. I'm supprised it is Apple, and pleased too. (I can't count NeXT because I never had admin on one, and can't say how drool proof that part was -- at least if it was actually first I'm only delaying it's credit to recognise it now as OSX...)
Where to start?
OSX PB is time limited, but you get to refund it's price vs. the OSX release price. Not the worlds best deal, but not a total rip off.
All the older apps I rand under OSX ran just fine (it started up "Classic" which is almost certonally a modifyed OS 9). In fact other people have reported running 68000 programs like MacDraw 0.8 under Classic. Oh, and for anyone who has never seen it run to start an old app "under Classic" you put the mouse over it and click twice (or click on a document associated with it), if "Classic" isn't running it starts automatically (but slowly), then your old app starts, and you are thrown into a world of the past (the old nice task switcher is back and all). You can click on your new apps to get back. Not the best thing in the world, but pretty easy.
I have seen an app that didn't work right under Classic. Apple's own iMovie got a bad aspect ratio and was gennerally unplesent. I hope it is fixed for the release (in twoish months). Hell I hope there is a new public beta next week and iMovie works under it!
Of corse it takes a lot from old systems. It is NeXT after all. And better off for it. mostly. It is a shame they are using the Mach kernel. The network stack needs work. I have to down/up the ethernet every once in a while to keep it running. Sometimes I have to flush the arp cache. I hope that gets fixed in the release too.
Still under OS9 the mac crashed three times or more a day. Under OSX in three weeks I have had one panic. A few application crashes (actually a lot if you count some of the repetable ones I tracked down, but I was looking for the source of the crash). Zero hangs. Zero failure to un-sleep (it is on a laptop). Two or three "system getting slower and slower because the window system and/or finder looks like it is leaking memory" where logging out and in again made things "all better".
Not the kind of quality I would hope for in a Unix desktop, but far far far better then the old Mac OS, or Windows. And I can allways hope it gets better in the release.
Name 10 people in your direct vicinity that use Windows wissler right now. Tell me that hunk of crap won't be mainstream within six months of release.
I fully expect Apple to be the biggest Unix seller by volume (not dollars!) when OSX gets bundled with all new Macs ("this summer"). Is that mainstream? Well Apple has a pretty low desktop share, and OSX will take a while to help it. It'll sure be mainstream for video editing systems though, and people who shoot comercials digitally, and some other markets. It'll sure deserve the mainstream more then Windows. And until Linux/FreeBSD/whatever gets a nice candy coated shell that my mom can use, it'll deserve the mainstream more then the other Unix systems as well.
Honda didn't show me a VW. Honda didn't try to make my wife look at an accord rather then a Civic. They did try to convince her to buy a 4 door rather then two door, and the "wrong" color. But not very hard. (they had no two doors in the lot in the trim line she wanted, and they only had the wring color too). [of corse I'm guilty of making my wife look at things other then the Honda Civic]
Volvo didn't try to sell me a VW or Audi even though they were in the same dealership (in the same big room even). They didn't even point me at a diffrent color or trim line. Then again I actually wanted something off the lot.
Of corse the last time I bought anything (modestly costly) at a retail chain they questioned my choice. I bought a DISH reciever to replace my existing one, and they wanted to sell me DirectTV. I wanted the Phillips 60hr TiVo and they wanted to sell me a Sony 30 (or the Sony + DirectTV 35).
What's so amazing? That we give emotion a role in selecting entertainment while we avoid it in writing code? Maybe because entertainment is in large part emotion, and code is only in tiny part emotion?
To me it wan't the best book in the world. It felt that way when I was 15 and reading it the first time. It doesn't make my personal top 100 anymore, but it still gets to be "worth the read".
In SF plausability isn't even that big of a deal as long as there is internal consistancy. If you read Asmov's robot tales they arn't very plauable (at least they don't seem so plusable anymore). But they are internally consistant.
I agree the tipical Niven style has no charactor devlopment (unless mind control or eating a plant counts). That makes his novels hard for some people to enjoy, while his short stories remain great.
However I'm not quite as negitave, I like his novels as well, just not as much as his short stories. I like his older work more then his newer, but I'm not sure how much of that is him, or me.
The one exception? Destinies Road. Decent plot and charactor devlopment, and decent wonders as well :-) It was a late 90s book, and IMHO his best novel.
As far as I could tell from the two hour long quicktime they all have slots for a second CPU, but jobs didn't think supply would match demand on the faster CPUs and they are not offering the second CPU except thruough channel partners (read "very expensave").
He also seemed to say the G4 PB wasn't actually available until the end of the month. Which sucks because I want to return my G3 one right now for the G4 :-)
Of corse the G4 one also says it won't run OSX-PB2, so I may have to wait two months for the real relase...
I think it is encode speed, but I can't find my "VIS Propaganda Manual" anywhere. I'm pretty sure the pixel-distance instruction that does the work of about 40 other instructions in a single cycle and most of the work a macro block needs made it a whole whole whole lot faster.
I'll look for the thing when I get back to work, it may be on my bookshelf there. If it wern't for the fact that I know the pixel distance instruction is useless to a decoder I would doubt my memory.
To Job's credit Sun did such a stunningly poor job of selling that feature, that iDVD on the Mac years later still looks stunning. Even to me :-)
The Sun ULTRA2 (or maybe ULTRA1?) can do two NTSC size MPEG2 streams at once using the "VIS extensions" (which are a bit like AltiVec, SSE/SSE2/3DNow/all the other SIMD extensions). I don't know if that includes an audio track, or disk I/O. The ULTRA2 is many years old and no longer sold by Sun. I assume the newer systems can do a way better job.
Note: the Ultra2 may not be all that fast, but I think the PDIST (or PDIFF?) instruction is extreamly MPEG2-codec-centric and helps make up a lot of ground in this benchmark.
Eh? OSX (at least PB2) has ping, it also has ssh, and apparently a telnet (I've never used it). It also has traceroute. Oh, and vi (so it isn't a network tool, but it is funny to see it on a Mac...).
Unfortunitly it also seems to have a lame DHCP client (how do you get it to ask for a new lease? Down the interface, delete all addresses, and bring it up; what do you do if networking vanishes for no reason? Try flushing the ARP cache).
Really? Does she use the web at all? OS9's MSIE crashed about twice a day for me, and Netscape made the system plenty unresponsave. Oddly enough OSX's MSIE crashes way way less offen (once in the week I have had it), which is kinda odd given that it is a beta of a product for a beta OS that it is more stable then their release product for a release OS.
I do hope Apple gets people to go from OS9 to OSX. If Apple can finish up device support for OSX and get the finder a little more usable I don't see much advantage to sticking with OS9.
I think you can hit $500 with a lame monitor and ditching the FireWire. I havn't ever used the FireWire on my Mac (my digital camera is USB, and even if I had FireWire devices OSX-PB2 doesn't have support, and I'm running OSX-PB2....).
Don't forget that with the iMac you will be replacing the mouse, and if you have carpal tunnel the keybord (not a huge deal, but still...).
The big reason I dislike the iMac is the built-in monitor. The monitor is one of the few upgrade durable parts of a system. Get a good one an it isn't a big deal to keep it for a decade. The iMac takes that away.
On the other hand, as another poster said their notebooks are pretty good for the money.
NASA - Symphonies Of The Planets, Volume 2 at least is the voyeger recordings. Cdnow doesn't have it, but half.com does (for les then $5 for many of them).
Enjoy.
I didn't really have much to save until about 3 years after i left collage. I didn't really start doing it until about five.
How does pension work in the UK? Here we pay social security, which will probbably not give us a dime when we retire. We can pay into a few tax exempt savings plans that can pay out tax free when we retire (or with taxes before that, or can be borrowed against for some things) and that normally goes through an employer, sometimes they throw in a little, or do some matching.
Unless there is a big tax break, you may just want to start by having a money market account or the like, it won't grow as fast in the long run, but it will be avilable for more kinds of emergencies.
Better yet, hire a finincal planner (not now, when you have money to save). It was probably the smartest money I ever spent.
I hear you. I don't regret getting mairred either, even though it pretty much made me give up consulting as my main income source (which cut my pay by 70%, and made me drop out of collage).
Sure, if enough prople did it. But I expect most people buying a Dreamcast will buy some games even if they want to hack a Unix onto it. Plus if enough people were hacking Unix onto it to be a problem, Sega could "just" build the system profit into the Ethernet (roumored to be on sale RSN). Unix geeks can't resist an ethernet, can they? :-)
Most video game systems break even when two games are bought for it. I have nine (and and 4 Sega controler purchases, and two VMUs), so I can handle at least 3.5 free loaders. Who wants to sign up?
Seriously Sega has a much smaller problem here then iOpener, or web-runner because even if we hack the box, they still provide a service. I mean it would be cool to play nethack ont he dreamcast on my TV, but it isn't going to replace Sega Bass Fishing now is it?
It does, but only because the Toshiba (or Yamaha?) play to be the first sellers of 1G CD-RW systems failed. Mosty because nobody wanted them. Many can still write them! They can't be read on normal CD-ROMs, so people wern't intrested. It fizzled, and then later Sega licenced it.
The Dreamcast can also read normal CDs, otherwise we wouldn't have any music :-)
In most states they owe you two weeks pay. I think they owe you a bit of warning (say half an hour), but there is no law that I know of that says that.
Nah, people just starting out may not make enough (I know I didn't). People with a family may not.
Being fired? Yeah, you should be able to see that well in advance. Getting layed off? Well if hte compony isn't public, there may be scant little chance that you know in advance.
If you can afford to save, it's a good idea. You may need it, could be lay offs, could be a family emergency, could be anything. But not everyine can afford to do it.
When I worked for MP Games in 1992 (a small coin-op maker, once part of Microprose) the arcade monitors were pretty much not very impressave. The were standard NTSC monitors frequently pushed a bit beyond spec. They were chosen mostly baised on size, and price. Color rendition and sharpness and so on were not as important. I was given to understand that that was pretty much industry standard.
This is in sharp contrast to the controls where feel and durability was (mostly!) more important then price.
The color fidelity didn't get corrected for since diffrent batches would have diffrent shifts. The bleed of the screen was sort of taken into account, in that antialiasing wasn't really done except by assuming the monitor would do a bit of color bleed (which is why things like GL mame look a bit more like the originals then stright mame).
Sharper will probbably not look much better (colors will look nicer, but the graphics will look a little more pixelated).
Depending on the era of your machine, and the maker your milage may vary of corse. A few games probbably didn't use normal NTSC monitors, or use high quality ones. But in '92 it was not common, and before that I doubt it was common except for vector games.
My guess is that the paper and Compaq have slightly diffrent definitions of SMT. I assume the paper chose one the author thought was intresting, or easy to evalulate, or easy to implment, or most constructave to evalulate, and Compaq chose one that would give good value for the design and transistor investment.
Given that very little existing software could use all-in-one-MMU-context SMT (multithreded programs only, and only CPU bound ones would take much advantage), and pretty much any CPU bound server workload (anything with more then one process) could take advantage of SMT with multiple MMU contexts.... of corse that assumes the implmentation cost isn't too horrific, but given that they picked it...
Anyway, if you do get another copy of the paper I would love to see it. Even if it doesn't exactly address Compaq's SMT, it sounds intresting. I can't find it with google, but maybe if you remember the title of the paper, or any authors other then Prof Berger?
Who says the threads all need to be from the same context? I asked a compaq guy about that 14 months ago and he said they cold be from diffrent VM contexts, and (and this was a supprise to me) load/stores in diffrent MMU contexts can be done in one cycle.
I don't recall if he was on the EV8 team, but he was in their CPU design department (his focus was on heat though).
Do you mean rad-hard as in "can take a rad hit, and then read back the old data later", or "read proper data durning a rad hit"?
If it just has to work OK after a rad hit a masked ROM is inharently rad hard (it isn't a set of fuses that can be blown, it is a set of WIRES). Masked ROMs use to be quite cheep in reasonable quantity (100+). They also use to have wonderful density and speed. However MROM has lost a lot of research funds as flash has basicly eaten 90% if it's market (and even more severly into EEPROM). I think MROM is not only used when cost is a huge issue, and changes are not beleved to be needed (like maybe by Handspring...). You may have to set the way-back machine to about 1994 for memory size, but that is still a lot better then 16Kbytes!
As long as you want masked ROMs smaller then about 16Mbits (2Mbytes) they should be pretty cheep. Like cheep enough to go into Super Nintendo cartrages (or at least N64 -- I think SNES made do with far far far smaler cartrages)
Fine, but reliable ATM has ACKs, so a ATM with 1024 byte packets would have 1024 byte ACKs. And would not have TCP ACK compression (which can send half as many ACKs, or less, if traffic is moving fast enough), and will miss many of the other fine TCP features.
My only dirrect experiance with a reliable ATM product was wholey negitave. It managed to carry about 2Mbits over a 16Mbit pipe. It was a disaster. Replacment with Frame Relay was a wonderful success, carrying almost 16Mbits within two hours of being turned up. Part of this was assuradly the hand-off media (but no more then 8Mbits loss could reasonable be attributed to that), and part was assuradly the poor hardware implmenting reliable ATM, but a large part was the poor reliable ATM itself, and the complexity which made it hard to have a good implmentation!
I know ATM was designed to carry voice phone traffic, but an ATM with 1024 byte headers would not be useful. Too much data would be in it. You can't buffer 1K byte (8K bits) of a 56Kbit voice stream without introducing audable latency. Existing 46 (or is it 36?) byte cells sometimes go unfilled in voice applications.
In other words a fixed 1024 byte ATM cell size will make ATM extreamly unwealdy. Far worse then existing ATM which is widly cratisized for throwing away ~33% of the banswidth.
Big deal. Optically switched IP would switch at the speed of light as well. Neither are likely to happen soon. The only thing that switches at the speed of light is the extreamly unflexable lambda switching, and that is all we are likely to have for quite some time.
It is a way to run IP over X, and I don't think it can run anything but IP. However X is a lot more then ATM or Frame Relay. It includes Packet over Sonet (which is basically a no-overhead no-service protocall), there is also a MPLS over PPP. I think there is a MPLS over ethernet as well. In practice there can be MPLS over anything. In reality it works better with things that can send either variable sized packets (with a large minimum size), or continous streams of data.
MPLS over ATM or Frame Relay is there more to get experaince with MPLS then to actually be used. You are right if you have allready payed for ATM or Frame Relay there seems to be little point in slapping MPLS onto of it before going for IP. MPLS was intended to be run very close to the wire, not on top of a complex protocall that does everything MPLS does and more. MPLS was a reaction to the loss of ATM and Frame Relay at higher speed interfaces.
I had no hand in deigning MPLS, I was merely on the same floor as some of the people that did. But, I have talke to them a bit. (I have only slightly more to blame for PPP over Ethernet)
There is some small chance that if MPLS is wildly succesful, one might want to run it over ATM or Frame Relay just because MPLS links are simpler to mangage. However I think chances of that are slim. I don't expect MPLS to be signifigantly more managable then Frame Relay or ATM, dispite being designed in large part by those that will have to manage it!
1024 bytes will suck for carrying an IP packet that is just a TCP ACK (and about 30% of TCP traffic is dataless ACKs). It also sucks for carrying interactave voice traffic (i.e. phones). The duel sized ATM-varient actually has almost all the advantages of ATM at the hardware level. It is *almost* as easy to support two sizes as just one, and a far bit simpler then supporting true variable size packets.
It was simpler to ignore "something like" then to guess how much like ATM you wanted.
It is really a stright forward attempt to get the advantages of IP over Frame Relay without all that complex Frame Relay stuff. And it is simpler then Frame Relay, and ATM, at least if you compair them fairly. At the packet level it is series of 16 bit tags followed by data (over ethernet this lives where the data normally lives, and there is a MPLS protocall number). Each MPLS switch pops off the first tag, and sends the packet out that interface. Simple enough to do cut through routing all in an ASIC without even a CAM involved. ATM needs a small CAM, or a large (but managable) lookup table. Same for Frame Relay. Both have extra fields to mostly ignore.
If you had an ethernet design in VHDL you could probbbly make a (non cut through) MPLS switch in less then 200 lines of VHDL, and definitly fewer gates then 802.1Q (or whatever the VLAN spec is); of corse it would be a MPLS that doesn't let anything else assign it's tags, but hay, what do you want for an hour's work?
All three have complex "call setup" schemes, and fallback schemes for dealing with link failure. The MPLS ones are several orders of magnitude simpler if you take statments like "use BGP to find a normal IP route, and do a trivial conversion to MPLS tags" at face value. Otherwise the MPLS ones are only somewhat less complex. ATM and Frame Relay have the notable advantage of being out there and tested for quite some time now. MPLS isn't over it's teething problems.
The biggest issue that MPLS haddn't fully grappled with as of the, um 1998 or early 1999 MPLS confrence was dealing with circuit failure. As far as I could tell they wanted something that delt faster then an ATM re-route, but without "waisting" half the bandwidth like a protect circuit, or a SONET ring. The big issue is if it takes 30 seconds while routing reconverges and they have to throw away a lambda of data, well, that is just a whole crap load of data to drop.
Oh, and of corse the "until there is a large scale deployment, nobody knows for sure it won't have nasty problems in a large scale deployment" problem. Of corse it's not like a faster ATM scheme wouldn't also have that problem. I mean the first UUNET ATM backbone had serious teething problems, and ATM switches should have been a well tested technology in 1993 (or was it '94?), right?
Granted my networking experence is mostly limited to IP, things you can run on top of IP, and things IP can run on top of. But I'm pretty damm sure of all the statments I've made.