Righto - I had Y-axis on the brain. The typical configuration for IOMeter has it ramp queue depth logarithmically. I could shift the axis to linear, but there would be missing data points. Adding tests to fill in those points adds greater risk of fragmenting the drive during the test.
Excellent observation on the file copy test. I'll take that on board as well.
evanbd - if you see this, lets continue via email.
Why don't comments from the story submission carry over to the article when posted? Most of the answers here were already commented on under the submission:
It would, but don't do it with that one or you'll fry either the board. They rewired the internal connectors so they could pass 2 channels over a single SATA connector. The SATA data lines passed via the power connector IIRC, so yeah, don't do it:).
> I find the average transaction time graphs hard to read. The semi-log plot format is a bit odd. It's also a bit hard to see relative changes when everything interesting is in the bottom 25-50% of the graph. Relative performance of two drives is easy enough to see, but between the semi-log plot and the sparse grid lines, it's really hard to see the scaling effects you're talking about.
Agreed, and I thank you for the feedback. The data itself is logarithmic, not the scale. Highly optimized drives produce a flat output while drives without NCQ support will show as logarithmic. The graphs were really useless for SSD's the way we used to present them. I continue to work on better ways to present the data without overloading the average reader.
4KiB by itself is not enough, it needs to be done at different queue depths as well. I do collect data on that but it's not part of the standard set of graphs we put out. Our Workstation test gets close enough on that one, and uses a more realistic mix of reads and writes. Nobody hits their drive with 4KiB random writes all day, so I refrain from going with those specific numbers.
Starting with the review prior to this one, I revised the Average Transaction Time graphs to show something more along the lines of what you might have been looking for.
The main issue with the JMicron controllers is the latency occasionally spikes to closer to half a second when hitting it with random writes. The other issue is that during this latency spike, even reads hang, leading to the 'stuttery' issues with those models. The 602B controller was supposed to address this, and it did to some degree, but not enough to compete with Indilinx and especially Intel. I've noted Samsung drives to be stuttery as well, but only after you've hit it with a bunch of random writes and fragmented it beforehand.
This little tidbit is available in the full version of the article text:
In 1982, a three-kiloton explosion tore apart a natural gas pipeline in Siberia; the detonation was so large it was visible from outer space. Two decades later, the New York Times columnist William Safire reported that the blast was caused by a cyber-operation planned and executed by the CIA. Safire's insider sources claimed that the United States carefully placed faulty chips and tainted software into the Soviet supply chain, causing the chips to fail in the field. More recently, unconfirmed reports in IEEE Spectrum, a mainstream technical magazine, attributed the success of Israel's September 2007 bombing raid on a suspected Syrian nuclear facility to a carefully planted "kill switch" that remotely turned off Syrian surveillance radar.
To those having a beef with our article page count:
- We have one bench per page (like everybody else), we do 7 benches. - We have an intro and conclusion (like everybody else). - I include several discussion pages and evaluate fragmentation-over-time and other important topics related to SSD performance, making the SSD pieces a few pages longer than the HDD pieces.
The additional content takes considerably more time to properly evaluate and discuss, but that is us going the extra mile for our readers. It's why people follow our site, and it's why I write for them. Our general rule of thumb is that a page should not go too far past the page side bars, which makes sense visually and is in-line with every other site I've seen out there. I could have rolled the testbed page in with the preceding page, but that page was already quite long due to additional content present. Feel free to use the page selector at the bottom of each page to jump around the article - that's what it's there for.
If you want some random smattering of benches with no analysis or additional editorial content, you're reading the wrong article, folks.
> The complete lack of text on the task bar means I have to learn what each icon represents and then have to mouse over it or open the item to figure out what it actually is.
Right click taskbar and change the setting so it shows you text like it used to. You can even disable grouping if you are so inclined.
> Am I annoyed that Windows still doesn't have very good window management and that I can't get rid of the annoying borders on my windows that the Bespin KDE theme lets me annihilate? You bet.
You can slim the borders considerably. IIRC it's "border padding" under advanced options. I've also found that dropping the title bar size to the minimum, when combined with the former border padding tweak, makes window sizes/proportions identical to XP using the classic theme.
XGPS is completely free (if you are willing to jailbreak) and covers most of the points above. There is a PC-side utility that lets you pull down Google map areas at a specified zoom level and send the created database directly to your iPhone. This has allowed me comfortable use of GPS features on my T-Mobile connected iPhone (without a data plan). The only internet connectivity needed is for route calculation / recalculation, but that too is partly negated by the fact that you can pre-query a route and save it in an offline list. I just calculate my routes before I leave my wifi zone. To break it down for those unaware: 1. XGPS has voice nav. It's cheesy, but it's there. 2. XGPS gives you the heads up turn warnings, along with a distance to next turn counter on-screen. 3. XGPS will recaclculate routes on the fly as you miss turns, but this requires internet connectivity. 4. TOMTOM wins that one - only one destination per route. You would have to make multiple routes. 5. Many (if not most) people using their iPhone in a car have it connected through an iPod-aware head unit or an adapter with iPod controls, so song changes and such take place in the background anyway.
With that sort of competition out there, no semi-technical iPhone user is going to blow $99 on an app. Think about it - you can get *an iPhone* for that now. Even being a happy XGPS user, I have been waiting for TOMTOM to come out and was considering getting a copy myself, but $99? That's just crazy talk. It's just software. Drop it to $20 and they'd have my business (and likely the business of many others). At $99 it becomes a bragging rights app, and those who truly want bragging rights already have that with XGPS. Even the clunky standard Google-driven app on the iPhone is 'good enough' to avoid blowing $99 on something that mostly "duplicates functionality" already present.
I have been working closely with OCZ on this new firmware and wanted to clear things up a bit. This new firmware *does not*, *in any way at all*, remove or eliminate orphaned data, deleted files, or anything of the like. It does not reach into the partition $bitmap and figure out what clusters are unused (like newer Samsung firmwares). It does not even use Windows 7 TRIM to purge unused LBA remap table entries upon file deletions.
What it *does* do is re-arrange in-place data that was previously write-combined (i.e. by earlier small random writes taking place). If data was written to every LBA of the drive, then all files were subsequently deleted, all data would remain associated with those LBAs. This actually puts OCZ above most of the pack, because their algorithm restores performance without needing to reclaim unused flash blocks, and does so completely independent of the data / partition type used. This is particularly useful for those concerned with data recovery of deleted files, since the data is never purged or TRIMmed.
Slashdot-specific Translation: This firmware will enable an OCZ Vertex to maintain full speed (~160 MB/sec) sequential writes and good IOPS performance when used under Mac and Linux.
Hardware-nut Translation: This firmware will enable OCZ Vertex to maintain full performance when used in RAID configurations.
I'll have my full evaluation of this firmware up at PC Perspective later today. Once available, it will appear at this link: http://www.pcper.com/article.php?aid=760
Regards, Allyn Malventano Storage Editor, PC Perspective
Well said. I've found using an ICH-10R kills that overhead, and I have seen excellent IOPS scaling with SSDs right on the motherboard controller. I've hit over 190k IOPS (single sector random read) with queue depth at 32, using only 4 X25-M G1 units. The only catch is the ICH-10R maxes out at about 650-700 MB/sec on throughput.
First a quick clarification: Intel X25 series SSDs do not use their RAM as a data writeback cache. Intel ships racks full of both M and E series drives, with those drives living in a RAID configuration. They couldn't pull that off if the array was corrupted on power loss. The competition had to start using large caches to reduce write stutters and increase random write performance, mostly in an attempt to catch up to Intel.
The parent article is a bit 'off' as far as bandwidth vs. IOPS on RAID controllers. You can saturate even the best PCI-e RAID cards with only spinning disks. I'm currently pegging an Areca with 10 1TB 5400 RPM drives. The ultimate bandwidth is not limited by bus speed - it is the speed of the internal data pipelines within the card itself. I have yet to see a RAID card pull anywhere close to the theoretical 2 GB/sec possible over PCI-e x8. The 24-drive crazy Samsung RAID video that's floating around required three different RAIDs going in parallel to hit 2 GB/sec.
What people also need to realize is that high end RAID cards were built around a theory of using a large cache and a dedicated processor to handle XOR calculations for RAID-5 and 6. Even the best performing cards will, at best, perform on-par with a high IOPS SSD like an X25 series.
The parent article also speaks briefly of Native Command Queuing, hinting that it is not implemented in RAID cards. This is flat out wrong:
The *real* reason even the best RAID hardware does not scale properly with SSD usage is the fact that a good RAID card has an upper IOPS limit matching just *one* SSD. Adding more SSDs only increases throughput, and it takes roughly half the number of SSDs to saturate a given controller (as compared to using HDDs).
The parent article heavily confuses 'streaming' with 'IOPS'. A given RAID card can 'stream' just as well with either HDDs or SSDs. Where 'IOPS' comes into the equation is how far your average throughput drops as those requests become more random in nature. Random accesses cause the RAID controller to have to juggle more data. Here is an example: Placing an X25-M G2 behind an Areca RAID card will result in a *reduction* in IOPS, but no change in sequential throughput. The RAID card processor simply can't juggle the commands as fast as if that same X25-M G2 was connected to the motherboard controller directly. With a single SSD outmaneuvering the RAID controller, adding more SSDs only helps the RAID scale in sequential throughput, not IOPS.
For SSDs to behave properly behind a RAID, the entire RAID process needs to be rethought. You don't need a bunch of writeback cache and a bulky controller architecture. You need a very lightweight XOR engine with *no* cache. The best example of this is creating a RAID of SSDs on an Intel ICH-10R controller. IOPS scales beautifully. 3 or 4 X25s on an ICH-10R will even outmaneuver an ioDrive, and gives several times the IOPS performance of any RAID card.
My personal X25-M (the one that started all of my reviews and Intel's subsequent patching of the fragmentation slowdown issue with the X25-M series), has had over 10 TB of data written to it. Most of those were sequential writes spanning the entire drive (HDTach RW passes). SMART attribute 5 on that drive is currently sitting at a whopping "2". That equates to only 8 bad flash blocks. It's actually been sitting ag 2 for a while now, so those blocks were likely early defects.
I suspect it will take most users *way* over a year to write greater than 10 TB to their 80 GB OS drive. Considering mine is still going strong after that much data written, I don't think there's anything to worry about.
Most sequential throughput benches hit the drive with sequential requests, and are not multithreaded. You end up seeing throughput lower than the theoretical interface bandwidth because of the latency involved for each request. A queue depth of 2 or 4 will give an X25 enough heads up to truly saturate the bus. I've recorded as high as 285 MB/sec from an X25-M using an NCQ-capable benchmarking tool.
Also, don't forget SATA uses 8/10b encoding, so you have to account for that overhead as well when calculating theoretical maximum throughput. Doing the math, you'll find 285 comes to 95% of a 3 GB/sec SATA interface. That's way higher than 200 MB/sec and close enough to call saturated.
I would normally agree with you, but terrain-following radar is quite unnecessary over open ocean. Unless of course you plan on dodging swells with an airplane.
Use an efficient antivirus like NOD32 and the performance hit will be significantly smaller, if detectable at all. The Symantec and McAfee real-time scanners bring most systems to a crawl, while ESET's engine is extremely lean.
The TRIM spec is not yet final, and most SSD's will not support it until it is. It's also a safe bet that the WIndows 7 RC does not yet issue TRIM commands (for the very same reason). My testing suggests TRIM is *not* yet at play in the 7100 build of 7. The *slight* gain in write performance seen in the linked review is likely due to the fact that they used two different firmwares for the supposed TRIM enabled / disabled testing. TRIM on a Vertex would give you more than the gain they saw.
I can judge character just fine regardless of my affiliation. The average Slashdot reader is not going to have enough context to get that you were poking fun. Heck, I had the context and still saw it as a low blow. Next time try throwing in a smiley for clarity.
Slashdot Mirror
Righto - I had Y-axis on the brain. The typical configuration for IOMeter has it ramp queue depth logarithmically. I could shift the axis to linear, but there would be missing data points. Adding tests to fill in those points adds greater risk of fragmenting the drive during the test.
Excellent observation on the file copy test. I'll take that on board as well.
evanbd - if you see this, lets continue via email.
Allyn Malventano
Storage Editor, PC Perspective
Why don't comments from the story submission carry over to the article when posted? Most of the answers here were already commented on under the submission:
http://slashdot.org/submission/1120256/Simple-Free-Web-Remote-PC-Control
If comments don't carry over when the submission gets picked up, what is their real purpose?
It would, but don't do it with that one or you'll fry either the board. They rewired the internal connectors so they could pass 2 channels over a single SATA connector. The SATA data lines passed via the power connector IIRC, so yeah, don't do it :).
http://www.pcper.com/article.php?aid=821&type=expert
Allyn Malventano
Storage Editor, PC Perspective
http://www.pcper.com/comments.php?nid=7615
> I find the average transaction time graphs hard to read. The semi-log plot format is a bit odd. It's also a bit hard to see relative changes when everything interesting is in the bottom 25-50% of the graph. Relative performance of two drives is easy enough to see, but between the semi-log plot and the sparse grid lines, it's really hard to see the scaling effects you're talking about.
Agreed, and I thank you for the feedback. The data itself is logarithmic, not the scale. Highly optimized drives produce a flat output while drives without NCQ support will show as logarithmic. The graphs were really useless for SSD's the way we used to present them. I continue to work on better ways to present the data without overloading the average reader.
Allyn Malventano
Storage Editor, PC Perspective
4KiB by itself is not enough, it needs to be done at different queue depths as well. I do collect data on that but it's not part of the standard set of graphs we put out. Our Workstation test gets close enough on that one, and uses a more realistic mix of reads and writes. Nobody hits their drive with 4KiB random writes all day, so I refrain from going with those specific numbers.
Starting with the review prior to this one, I revised the Average Transaction Time graphs to show something more along the lines of what you might have been looking for.
Allyn Malventano
Storage Editor, PC Perspective
The main issue with the JMicron controllers is the latency occasionally spikes to closer to half a second when hitting it with random writes. The other issue is that during this latency spike, even reads hang, leading to the 'stuttery' issues with those models. The 602B controller was supposed to address this, and it did to some degree, but not enough to compete with Indilinx and especially Intel. I've noted Samsung drives to be stuttery as well, but only after you've hit it with a bunch of random writes and fragmented it beforehand.
Allyn Malventano
Storage Editor, PC Perspective
Did said think tank read this?
http://www.foreignaffairs.com/articles/65499/wesley-k-clark-and-peter-l-levin/securing-the-information-highway
This little tidbit is available in the full version of the article text:
In 1982, a three-kiloton explosion tore apart a natural gas pipeline in Siberia; the detonation was so large it was visible from outer space. Two decades later, the New York Times columnist William Safire reported that the blast was caused by a cyber-operation planned and executed by the CIA. Safire's insider sources claimed that the United States carefully placed faulty chips and tainted software into the Soviet supply chain, causing the chips to fail in the field. More recently, unconfirmed reports in IEEE Spectrum, a mainstream technical magazine, attributed the success of Israel's September 2007 bombing raid on a suspected Syrian nuclear facility to a carefully planted "kill switch" that remotely turned off Syrian surveillance radar.
Yup. No Cyberterrorism to see here. Riiiight.
Funny how they 'fixed' this just in time for SSDs to start catching on, so now hard drives will be 'correct' and SSD capacity will be misreported.
Allyn Malventano
Storage Editor, PC Perspective
To those having a beef with our article page count:
- We have one bench per page (like everybody else), we do 7 benches.
- We have an intro and conclusion (like everybody else).
- I include several discussion pages and evaluate fragmentation-over-time and other important topics related to SSD performance, making the SSD pieces a few pages longer than the HDD pieces.
The additional content takes considerably more time to properly evaluate and discuss, but that is us going the extra mile for our readers. It's why people follow our site, and it's why I write for them. Our general rule of thumb is that a page should not go too far past the page side bars, which makes sense visually and is in-line with every other site I've seen out there. I could have rolled the testbed page in with the preceding page, but that page was already quite long due to additional content present. Feel free to use the page selector at the bottom of each page to jump around the article - that's what it's there for.
If you want some random smattering of benches with no analysis or additional editorial content, you're reading the wrong article, folks.
Allyn Malventano
Storage Editor, PC Perspective
> The complete lack of text on the task bar means I have to learn what each icon represents and then have to mouse over it or open the item to figure out what it actually is.
Right click taskbar and change the setting so it shows you text like it used to. You can even disable grouping if you are so inclined.
> Am I annoyed that Windows still doesn't have very good window management and that I can't get rid of the annoying borders on my windows that the Bespin KDE theme lets me annihilate? You bet.
You can slim the borders considerably. IIRC it's "border padding" under advanced options. I've also found that dropping the title bar size to the minimum, when combined with the former border padding tweak, makes window sizes/proportions identical to XP using the classic theme.
XGPS is completely free (if you are willing to jailbreak) and covers most of the points above. There is a PC-side utility that lets you pull down Google map areas at a specified zoom level and send the created database directly to your iPhone. This has allowed me comfortable use of GPS features on my T-Mobile connected iPhone (without a data plan). The only internet connectivity needed is for route calculation / recalculation, but that too is partly negated by the fact that you can pre-query a route and save it in an offline list. I just calculate my routes before I leave my wifi zone. To break it down for those unaware:
1. XGPS has voice nav. It's cheesy, but it's there.
2. XGPS gives you the heads up turn warnings, along with a distance to next turn counter on-screen.
3. XGPS will recaclculate routes on the fly as you miss turns, but this requires internet connectivity.
4. TOMTOM wins that one - only one destination per route. You would have to make multiple routes.
5. Many (if not most) people using their iPhone in a car have it connected through an iPod-aware head unit or an adapter with iPod controls, so song changes and such take place in the background anyway.
With that sort of competition out there, no semi-technical iPhone user is going to blow $99 on an app. Think about it - you can get *an iPhone* for that now. Even being a happy XGPS user, I have been waiting for TOMTOM to come out and was considering getting a copy myself, but $99? That's just crazy talk. It's just software. Drop it to $20 and they'd have my business (and likely the business of many others). At $99 it becomes a bragging rights app, and those who truly want bragging rights already have that with XGPS. Even the clunky standard Google-driven app on the iPhone is 'good enough' to avoid blowing $99 on something that mostly "duplicates functionality" already present.
I have been working closely with OCZ on this new firmware and wanted to clear things up a bit. This new firmware *does not*, *in any way at all*, remove or eliminate orphaned data, deleted files, or anything of the like. It does not reach into the partition $bitmap and figure out what clusters are unused (like newer Samsung firmwares). It does not even use Windows 7 TRIM to purge unused LBA remap table entries upon file deletions.
What it *does* do is re-arrange in-place data that was previously write-combined (i.e. by earlier small random writes taking place). If data was written to every LBA of the drive, then all files were subsequently deleted, all data would remain associated with those LBAs. This actually puts OCZ above most of the pack, because their algorithm restores performance without needing to reclaim unused flash blocks, and does so completely independent of the data / partition type used. This is particularly useful for those concerned with data recovery of deleted files, since the data is never purged or TRIMmed.
Slashdot-specific Translation: This firmware will enable an OCZ Vertex to maintain full speed (~160 MB/sec) sequential writes and good IOPS performance when used under Mac and Linux.
Hardware-nut Translation: This firmware will enable OCZ Vertex to maintain full performance when used in RAID configurations.
I'll have my full evaluation of this firmware up at PC Perspective later today. Once available, it will appear at this link:
http://www.pcper.com/article.php?aid=760
Regards,
Allyn Malventano
Storage Editor, PC Perspective
Welcome to 2 weeks ago:
http://www.pcper.com/comments.php?nid=7544
Allyn Malventano
Storage Editor, PC Perspective
Well said. I've found using an ICH-10R kills that overhead, and I have seen excellent IOPS scaling with SSDs right on the motherboard controller. I've hit over 190k IOPS (single sector random read) with queue depth at 32, using only 4 X25-M G1 units. The only catch is the ICH-10R maxes out at about 650-700 MB/sec on throughput.
Allyn Malventano
Storage Editor, PC Perspective
First a quick clarification: Intel X25 series SSDs do not use their RAM as a data writeback cache. Intel ships racks full of both M and E series drives, with those drives living in a RAID configuration. They couldn't pull that off if the array was corrupted on power loss. The competition had to start using large caches to reduce write stutters and increase random write performance, mostly in an attempt to catch up to Intel.
The parent article is a bit 'off' as far as bandwidth vs. IOPS on RAID controllers. You can saturate even the best PCI-e RAID cards with only spinning disks. I'm currently pegging an Areca with 10 1TB 5400 RPM drives. The ultimate bandwidth is not limited by bus speed - it is the speed of the internal data pipelines within the card itself. I have yet to see a RAID card pull anywhere close to the theoretical 2 GB/sec possible over PCI-e x8. The 24-drive crazy Samsung RAID video that's floating around required three different RAIDs going in parallel to hit 2 GB/sec.
What people also need to realize is that high end RAID cards were built around a theory of using a large cache and a dedicated processor to handle XOR calculations for RAID-5 and 6. Even the best performing cards will, at best, perform on-par with a high IOPS SSD like an X25 series.
The parent article also speaks briefly of Native Command Queuing, hinting that it is not implemented in RAID cards. This is flat out wrong:
1. Only very high end cards properly implement NCQ at the host and drive level (i.e. Areca):
http://www.pcper.com/article.php?aid=695&type=expert&pid=6
2. Only some SSDs implement NCQ beyond a queue depth of about 4 (i.e. Intel).
http://www.pcper.com/article.php?aid=750&type=expert&pid=8
The *real* reason even the best RAID hardware does not scale properly with SSD usage is the fact that a good RAID card has an upper IOPS limit matching just *one* SSD. Adding more SSDs only increases throughput, and it takes roughly half the number of SSDs to saturate a given controller (as compared to using HDDs).
The parent article heavily confuses 'streaming' with 'IOPS'. A given RAID card can 'stream' just as well with either HDDs or SSDs. Where 'IOPS' comes into the equation is how far your average throughput drops as those requests become more random in nature. Random accesses cause the RAID controller to have to juggle more data. Here is an example: Placing an X25-M G2 behind an Areca RAID card will result in a *reduction* in IOPS, but no change in sequential throughput. The RAID card processor simply can't juggle the commands as fast as if that same X25-M G2 was connected to the motherboard controller directly. With a single SSD outmaneuvering the RAID controller, adding more SSDs only helps the RAID scale in sequential throughput, not IOPS.
For SSDs to behave properly behind a RAID, the entire RAID process needs to be rethought. You don't need a bunch of writeback cache and a bulky controller architecture. You need a very lightweight XOR engine with *no* cache. The best example of this is creating a RAID of SSDs on an Intel ICH-10R controller. IOPS scales beautifully. 3 or 4 X25s on an ICH-10R will even outmaneuver an ioDrive, and gives several times the IOPS performance of any RAID card.
Allyn Malventano
Storage Editor, PC Perspective
My personal X25-M (the one that started all of my reviews and Intel's subsequent patching of the fragmentation slowdown issue with the X25-M series), has had over 10 TB of data written to it. Most of those were sequential writes spanning the entire drive (HDTach RW passes). SMART attribute 5 on that drive is currently sitting at a whopping "2". That equates to only 8 bad flash blocks. It's actually been sitting ag 2 for a while now, so those blocks were likely early defects.
I suspect it will take most users *way* over a year to write greater than 10 TB to their 80 GB OS drive. Considering mine is still going strong after that much data written, I don't think there's anything to worry about.
Allyn Malventano
Storage Editor, PC Perspective
Most sequential throughput benches hit the drive with sequential requests, and are not multithreaded. You end up seeing throughput lower than the theoretical interface bandwidth because of the latency involved for each request. A queue depth of 2 or 4 will give an X25 enough heads up to truly saturate the bus. I've recorded as high as 285 MB/sec from an X25-M using an NCQ-capable benchmarking tool.
Also, don't forget SATA uses 8/10b encoding, so you have to account for that overhead as well when calculating theoretical maximum throughput. Doing the math, you'll find 285 comes to 95% of a 3 GB/sec SATA interface. That's way higher than 200 MB/sec and close enough to call saturated.
Allyn Malventano
Storage Editor, PC Perspective
I would normally agree with you, but terrain-following radar is quite unnecessary over open ocean. Unless of course you plan on dodging swells with an airplane.
Use an efficient antivirus like NOD32 and the performance hit will be significantly smaller, if detectable at all. The Symantec and McAfee real-time scanners bring most systems to a crawl, while ESET's engine is extremely lean.
The TRIM spec is not yet final, and most SSD's will not support it until it is. It's also a safe bet that the WIndows 7 RC does not yet issue TRIM commands (for the very same reason). My testing suggests TRIM is *not* yet at play in the 7100 build of 7. The *slight* gain in write performance seen in the linked review is likely due to the fact that they used two different firmwares for the supposed TRIM enabled / disabled testing. TRIM on a Vertex would give you more than the gain they saw.
Allyn Malventano
Storage Editor, PC Perspective
I can judge character just fine regardless of my affiliation. The average Slashdot reader is not going to have enough context to get that you were poking fun. Heck, I had the context and still saw it as a low blow. Next time try throwing in a smiley for clarity.
Troll much?
I never would have thought such a simple statement could in itself be a troll. Who knew?
I really thought the HotHardware guys would be better than that. Seriously.
Correction to my last. I was speaking of X25-M, not E.