If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#91
|
|||
|
|||
keith wrote:
On Tue, 30 Aug 2005 21:02:51 +0000, Bill Davidsen wrote: keith wrote: On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote: keith wrote: On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote: http://www.macworld.com/news/2005/08...core/index.php I simply found it an admission of how far (and for how long) their technological head is (and has been) up their corporate ass. Nine months in development isn't that big of a deal, given that the "cores" are already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! If these cores are the desktop versions rather than Xeon, they were not planned to be used in SMP, much less in dual core. I'd be interested to get your spin on why they *would* test the desktop chip SMP. Spin? Like to load them words, eh? One reason to do SMP testing is that it's "easy" to test cache coherence with two processors. Two processors can bang the caches pretty hard against each other. Not really, "spin" usually refers to how facts look from another viewpoint, which is just what I was after. But if the chip has no SMP logic, such testing would not be possible. The logic *is* there, though perhaps not brought out to the user. Regardless, Intel *has* SMP verification capability. The only excuse for such a stupid statement is that Intel has NIH burried so far up their ass that even the exec's can't wiff the nonsense. They *have* the test-cases. You keep saying this, please post a picture of an Intel P4 desktop chip with some arrows pointing to the SMP logic you state is present, or stop making the claim. How can Intel have capability to verify a non-existant feature? Or provide a link to an official Intel statement that the capability for SMP is present in non-Xeon chips. Do you really think Intel has no SMP verification capabilities? Do they not "borrow" tools from one organization to another? There's more here than meets the eye. Someone dropped the ball, big time! I really think the desktop P4 has no SMP capabilities, because they would take real estate and need to be tested. Not features you want in production. Irrelevant. They have SMP test and verification capability. If they needed it for dual-core, they didn't have to invent new material. To suggest such is simply silly. I say there are no capabilities to test and you say that's irrelevant, Intel can still test them. Please clarify. Here's a more interesting question: Intel built the D/C chips on P4 rather than P-M, presumably so they could offer the ht model at a huge premium. Given the low power and far better performance of the P-M in terms of work/watt and work/clock, why not a dual core Pentium-M? Then when the better P4 D/C chip is ready they could offer that? Absolutely. ...which makes the SMP verification issue even more strange. Just curious as to the logic for the decision if anyone has any insight. Search me. I've given up trying to explain Intel's moves; too bizare. In rethinking my question, I can see from a marketing point both HT and 64 bit are needed. HT is a bust. Everyone knew 64bits was needed five years ago. Intel tried to derail x86 and go with Itanic only. AMD decided otherwise. Where is Itanic? They sure have sold you that "you need 64 bit" hype, haven't they? That's why Intel couldn't use P-M, AMD convinced people it was necessary to have 64 bits. HT is a free way to get 15-30% more performance out of a CPU, if that's a bust I wish someone would bust my gas mileage. -- bill davidsen SBC/Prodigy Yorktown Heights NY data center http://newsgroups.news.prodigy.com |
#92
|
|||
|
|||
Bill Davidsen writes:
They sure have sold you that "you need 64 bit" hype, haven't they? That's why Intel couldn't use P-M, AMD convinced people it was necessary to have 64 bits. HT is a free way to get 15-30% more performance out of a CPU, if that's a bust I wish someone would bust my gas mileage. however, kernel smp overhead has been notorious for adding 15-30% overhead ... which can result in a wash. from 30+ years ago ... there was a project to add a second i-stream to 370/195. the issue was that 195 drained the pipeline on branches and most codes ran at around half pipeline and half peak thruput. the hope was that 2nd i-stream could get close to double hardware thruput (for wide-range of codes) ... more than enuf to compensate for any incremental kernel overhead going to smp kernel. it was never produced. originally 370/195 was targeted at national labs. and numerical intensive supercomputer type stuff. however, it started to see some uptake in the TPF market (transaction processing facility ... the renamed ACP ... airline control program ... which in addition to be being used in large airline res. systems ... was starting to see some deployment in large financial transaction networks, therefor its name change). the codes in this market segment was much more commercial oriented ... so a 2nd thread/i-stream might benefit the customers workload. the high-end TPF financial transaction market was seeing some uptake of 195 as growth from 370/168 (195 even running commercial codes at half peak could still be around twice thruput of 168). a big stumbling block was that TPF (operating system) didn't have SMP support and didn't get SMP until after 3081 time-frame in the 80s (the 3081 product was smp only ... but eventually they were forced to produce a reduced priced, single-cpu 3083 for the TPF market). the other issue was that 3033 eventually showed up on the scene which was nearly the thruput of half-peak 195 (about even on commercial codes). for some folklore drift sjr was still running 370/195 and made it available to internal shops for numerical intensive operations. however, the batch backlog could be extremely long. Somebody at PASC claimed that they were getting 3month turn-arounds (they eventually setup a background and checkpoint process on their own 370/145 that would absorbe spare cycles offshift ... and started getting slightly better than 3 month turn-around for the same job). one of the applications being run by the disk division on research's 195 was air-bearing simulation ... working out the details for floating disk heads. they were also getting relatively poor turn around. the product test lab across the street in bldg. 15 got an early 3033 engineering machine for use in disk/processor/channel product test. the disk engineering labs (bldg 14) and the product test labs (bldg 15) had been running all their testing "stand-alone" ... scheduled machine time for a single 'testcell" at a time. the problem was that standard operating system tended to quickly fail in an environment with a lot of engineering devices being tested (MVS had a MTBF of 15 minutes in this environment). I had undertaken to rewrite the i/o supervisor making operating system bullet proof so that they could concurrently test multiple testcells w/o requiring dedicated, scheduled stand-alone machine time (and w/o failing) http://www.garlic.com/~lynn/subtopic.html#disk when the 3033 went into bldg. 15, this operating system was up and running and heavy concurrent product test was consuming something under 4-5 percent of the processor. so we setup an environment to make use of these spare cpu cycles. one of the applications we setup to provide thousands of cpu hrs processing was air-bearing simulation (in support of working out details for floating disk heads). -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
#93
|
|||
|
|||
On Wed, 31 Aug 2005 10:33:25 +0200, Ketil Malde wrote:
keith writes: To address the original point YK raised, Intel still has the clear lead in low power for mobile. [...] They're focusing on mobile, there's no doubt there. At the same time Intel is leaving the high performance market to AMD. I think one important change is that the laptop market (like high performance) used to be a high margin area. Now that laptop prices have really plummeted, and Intel's laptop lead isn't as exclusive as its Xeon business used to be (sure, Centrino is nice, but you can always put together something similar based on AMD), it seems highly unlikely that it will give anything near the same margins. No argumennt here. The only "issue" is *may* be addressed by the antitrust suits. Certainly AMD has shown itself to be able to com here. ...at least in the technical sense. -- Keith |
#94
|
|||
|
|||
On Wed, 31 Aug 2005 15:18:59 +0000, Bill Davidsen wrote:
keith wrote: On Tue, 30 Aug 2005 21:02:51 +0000, Bill Davidsen wrote: snip Not really, "spin" usually refers to how facts look from another viewpoint, which is just what I was after. But if the chip has no SMP logic, such testing would not be possible. The logic *is* there, though perhaps not brought out to the user. Regardless, Intel *has* SMP verification capability. The only excuse for such a stupid statement is that Intel has NIH burried so far up their ass that even the exec's can't wiff the nonsense. They *have* the test-cases. You keep saying this, please post a picture of an Intel P4 desktop chip with some arrows pointing to the SMP logic you state is present, or stop making the claim. How can Intel have capability to verify a non-existant feature? Or provide a link to an official Intel statement that the capability for SMP is present in non-Xeon chips. Oh, please! The Xeons aren't that different than P4's, of any stipe. The PIIIs came in both SMP and non stripes. The PPro was SMP, so the P6 bus *is* SMP capable. Intel is well known to have SMP x86 capability. They have had the verification infrastructure for SMP for well over a decade. If there is a minor bus change that's a *small* issue, compared with verification. Product test is done by systems that don't care what the widget is. They only care about test vectors, which drop out of the architecture verification. I really think the desktop P4 has no SMP capabilities, because they would take real estate and need to be tested. Not features you want in production. Irrelevant. They have SMP test and verification capability. If they needed it for dual-core, they didn't have to invent new material. To suggest such is simply silly. I say there are no capabilities to test and you say that's irrelevant, Intel can still test them. Please clarify. Then I say, that you have no clue how these things are done. ...or you and Intel are in the same clueless boat. Somehow I doubt the latter. In rethinking my question, I can see from a marketing point both HT and 64 bit are needed. HT is a bust. Everyone knew 64bits was needed five years ago. Intel tried to derail x86 and go with Itanic only. AMD decided otherwise. Where is Itanic? They sure have sold you that "you need 64 bit" hype, haven't they? It is needed. Perhaps not today, but sooner than I'm going to replace this system. My Win-system is a Y2K replacement. That's why Intel couldn't use P-M, AMD convinced people it was necessary to have 64 bits. HT is a free way to get 15-30% more performance out of a CPU, if that's a bust I wish someone would bust my gas mileage. Oh, and Intel's marketeering is so grand, but AMD sucks? In reality Intel didn't want to go to 64b, except in Itanic. They were brought along kicking and screaming. ...as Itanic sank beneath the waves. I wonder why the architecture is called AMD64? Hmm. == Keith |
#95
|
|||
|
|||
keith writes:
Wasn't the 3033 a 3168 on steriods? ...complete with dual I-streams? 303x machines were organized to use the 303x channel director. the 370/158 had integrated channels ... i.e. the 158 engine was shared between the microcode that executed 370 instructions and the microcode that executed channel (I/O) programs. for the 303x channel director they took the 370/158 and removed the microcode that executed 370 instructions leaving just the channel execution microcode. a 3031 was a 370/158 remapped to use a channel director box i.e. a 3031 was a 370/158 that had the channel program microcode removed ... leaving the engine dedicated to executing the 370 instruction microcode. in some sense a single processor 3031 was a two 158-engine smp system .... but with one of the 158 engines dedicated to running 370 instruction microcode and the other processor dedicated to running the channel program microcode. a 3032 was a 370/168 modified to use the 303x channel director. a 3033 started out being a 370/168 wiring diagram remapped to new chip technology. the 168 chip technology was 4 circuits per chip. the 3033 chip technology was about 20% faster but had about ten times as many circuits per chip. the initial straight wiring remap would have resulted in the 3033 being about 20% faster than 168-3 (using only 4 cicuits/chip). somewhere in the cycle, there was a decision to redesign critical sections of the machine to better utilize the higher circuit density ... which eventually resulted in the 3033 being about 50% faster than the 168-3. basic 3033 was single processor (modulo having up to three 303x channel directors for 16 channels). you could get two-processor (real) 3033 smp systems (not dual i-stream). there was some internal issues with the 3031 being in competition with 4341 ... with the 4341 being significantly better price/performance. A cluster of six 4341s also were cheaper than a 3033 also with much better price/performance and higher aggregate thruput. Each 4341 could have 16mbytes of real storage and 6channels for an aggregate of 96mbytes of real storage and 36 i/o channels. A single processor 3033 was still limited to 16 i/o channels and 16mbytes. somewhat in recognition of the real stroage constraint on 3033 thruput .... a hack was done to support 32mbytes of real storage even tho the machines had only 16mbyte addressing. A standard page table entry had 16bits, 12bit page number (with 4k pages giving 24bit real storage addrssing), 2 defined bits, and two undefined bits. The undefined bits were remapped on the 3033 to be used in specifying real page numbers. That allowed up to 14bit page number ... with 4k pages giving up to 26bit real storage addressing (64mbytes). channel program idals had been introduced with 370 ... allowing for up to 31bit real storage addressing (even tho only 24bits were used). This allowed the operating system to do page I/O into and out of storage above the 16mbyte line. around the same time that the product test lab (bldg. 15) got their 3033, they also got a brand new engineering 4341 (for the same purpose doing channel disk i/o testing). we could co-op the 4341 in much the same way that the 3033 was co-oped. In fact, for a period of time, I had better access to the 4341 for running tests than 4341 product people in endicott did; as a result I got asked to run some number of benchmarks on the bldg. 15 4341 for the endicott 4341 product people. minor past refs: http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2001l.html#32 mainframe question http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2002b.html#0 Microcode? http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel? http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750) http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand? http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof some number of past posts on 303x channel director: http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ??? http://www.garlic.com/~lynn/97.html#20 Why Mainframes? http://www.garlic.com/~lynn/99.html#7 IBM S/360 http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning? http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout? http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001j.html#3 YKYGOW... http://www.garlic.com/~lynn/2001l.html#24 mainframe question http://www.garlic.com/~lynn/2001l.html#32 mainframe question http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel? http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?) http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033 http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad? http://www.garlic.com/~lynn/2003.html#39 Flex Question http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's http://www.garlic.com/~lynn/2004.html#9 Dyadic http://www.garlic.com/~lynn/2004.html#10 Dyadic http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware? http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#26 CAS and LL/SC http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode" http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30 http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof in the late 70s and early 80s, 4341 competed with and sold into the same market segment as vax machines http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?" http://www.garlic.com/~lynn/2001m.html#15 departmental servers http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750) http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750) http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha http://www.garlic.com/~lynn/2003c.html#19 diffence between itanium and alpha http://www.garlic.com/~lynn/2003d.html#0 big buys was: Tubes in IBM 1620? http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360? http://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why? http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package? http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"? http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions http://www.garlic.com/~lynn/2004.html#46 DE-skilling was ServerPak Install via QuickLoad Product http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Vintage computers are better http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware? http://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware? http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA? http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005n.html#10 Code density and performance? http://www.garlic.com/~lynn/2005n.html#11 Code density and performance? http://www.garlic.com/~lynn/2005n.html#12 Code density and performance? http://www.garlic.com/~lynn/2005n.html#16 Code density and performance? http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere? -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
#96
|
|||
|
|||
On Wed, 31 Aug 2005 12:30:44 -0600, Anne & Lynn Wheeler wrote:
snip the other issue was that 3033 eventually showed up on the scene which was nearly the thruput of half-peak 195 (about even on commercial codes). Wasn't the 3033 a 3168 on steriods? ...complete with dual I-streams? for some folklore drift sjr was still running 370/195 and made it available to internal shops for numerical intensive operations. however, the batch backlog could be extremely long. Somebody at PASC claimed that they were getting 3month turn-arounds (they eventually setup a background and checkpoint process on their own 370/145 that would absorbe spare cycles offshift ... and started getting slightly better than 3 month turn-around for the same job). 3mos? Wow. I had a friend that had a bank of '85s doing ASTAP (circuit sim) for 72 hours at a crack over the weekends. His boss didn' tmuch like the bill, but the "customer" (internal) wanted statistical tranisent runs. ....something today that could be done on this computer with some version of Spice nin a few hours, no doubt. one of the applications being run by the disk division on research's 195 was air-bearing simulation ... working out the details for floating disk heads. they were also getting relatively poor turn around. the product test lab across the street in bldg. 15 got an early 3033 engineering machine for use in disk/processor/channel product test. ....and you swiped it. ;-) Aside: I worked on the 3033. the disk engineering labs (bldg 14) and the product test labs (bldg 15) had been running all their testing "stand-alone" ... scheduled machine time for a single 'testcell" at a time. the problem was that standard operating system tended to quickly fail in an environment with a lot of engineering devices being tested (MVS had a MTBF of 15 minutes in this environment). At least you didn't *smoke* 'em. Customers *hated* that. Execs seemed to hat us for it. ;-) snip when the 3033 went into bldg. 15, this operating system was up and running and heavy concurrent product test was consuming something under 4-5 percent of the processor. so we setup an environment to make use of these spare cpu cycles. one of the applications we setup to provide thousands of cpu hrs processing was air-bearing simulation (in support of working out details for floating disk heads). You "stole" the CPU cycles. We had a ton of the systems on site, but they were off-limits to users (customer machines can't be toyed with). Indeed I killed one customer's ES9000. I pushed it over the power-on cycles looking for an intermittent bug. My boss had to buy all the TCMs. He wasn't happy, but they wouldn't buy (or rent) me a $10 logic analyzer either. So we spent weeks tracking down the bug and a few more patching it. -- Keith |
#97
|
|||
|
|||
already there. Years? Please! They don't simulate/verify in multi-processor environments? *Amazing*! Like the article says, Intel didn't have the test vectors or BIST for testing interconnects between the two cores. That's understandable as Intel was fabricating single-cores prior. Intel has accumulated a large suite of software diagnostics to verify SMP scenarios (#LOCK, APIC, cache MESI, etc) back when the Pentium II introduced built-in SMP logic (and before). |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMD upgrade to which dual core processor | www.interfacebus.com | General | 5 | August 14th 05 11:26 AM |
FS printers/parts trays, printheads -- oki fujitsu dl3700 dl3800 hp genicom epson ibm dec jetdirect laserjet lexmark qms okidata microline 320 ml320 393 tally printronix tektronix qms toshiba zebra otc ibm intermec 7755 boul st laurent montreal ca | cisco | Printers | 2 | May 22nd 05 02:05 AM |
Games that take advantage of 64 bit and/or dual core CPUs? | boe | AMD x86-64 Processors | 1 | April 21st 05 11:47 PM |
FS PRINTER PARTS trays fusers drums printheads -- oki fujitsu hp genicom epson ibm dec jetdirect laserjet lexnmark qms okidata ml320 mannesmann tally printonix tektronix qms toshiba zebra otc ibm lexmark intermec dec compaq montreal canada toronto o | [email protected] | Printers | 1 | March 15th 05 05:50 AM |
Dual Core Processors & MoBo | k_yhz | General | 2 | January 5th 05 08:43 PM |