Recommended Posts

From what I heard the higher capacity drives are a lot faster than the slower ones.

Isn't that a bit counter-intuitive? One would think that the larger the drive, the more the drive has to read through, so the slower it would be. I guess I don't know enough about the actual process...

Isn't that a bit counter-intuitive? One would think that the larger the drive, the more the drive has to read through, so the slower it would be. I guess I don't know enough about the actual process...

.... and are also more expensive :(

Isn't that a bit counter-intuitive? One would think that the larger the drive, the more the drive has to read through, so the slower it would be. I guess I don't know enough about the actual process...

Often larger drives are faster due to the higher data density on the platters, or the amount of platters themselves, the amount of heads per platter, or a combination of all these, etc... There are many variables in effect to explain why a bigger drive is often faster than a smaller one, but the specifics are different from drive to drive.

Often larger drives are faster due to the higher data density on the platters, or the amount of platters themselves, the amount of heads per platter, or a combination of all these, etc... There are many variables in effect to explain why a bigger drive is often faster than a smaller one, but the specifics are different from drive to drive.

Exactly. Same amount of platters, same size (physical) platters, same rpm, and higher density = faster performance

The Force GT is definitely faster but not as instant what everyone claims SSDs are.

Installing Windows 7 takes 20 min (starting from setup screen next to drive partition) on Seagate while it takes 18 min on Corsair Force GT.

Speeds have settled to 140 mBps write and 230 mBps read which is a far cry compared to 550/550 write/read printed on the packaging.

The 550MBps ratings that you see on the specs are for sequential reads and writes. this would be like copying a giant iso or movie from a source to your SSD, or vice versa.

Just about every other I/O on your computer is going to be small-block random I/O. this would include installing and booting an OS, loading programs, etc.

when buying an SSD, the biggest thing you want to consider is the random performance, not the sequential.

Speeds have settled to 140 mBps write and 230 mBps read which is a far cry compared to 550/550 write/read printed on the packaging.

You are using SATA2 which bottlenecks your SSD, you should only get 230-270MB/s on SATA2.

You only see the speeds printed on the packaging if you are using SATA3 and only then if it is reading/writing sequential data, random reads and incompressible files (videos, music, games) are the Sandforce achilles heel.

The 550MBps ratings that you see on the specs are for sequential reads and writes. this would be like copying a giant iso or movie from a source to your SSD, or vice versa.

No, the SF-2281 is awful at reading/writing incompressible data like ISOs and Movies.

One thing I havent seen mentioned in here - with his controller/chipset - is it even SATA3 ?

Also, is he getting more than 1 PCIE lane ?

Reason I ask is, all of this ridiculous bickering about speeds would be moot if he is limited by something like that.

For instance, since I have a x58 chipset (original Core i7) I am limited to 400MB/sec due to PCI-Express bandwidth issues.

I have a Vertex 3 in my desktop & cant get better than 400MB/sec - but it matters not since I boot up in 12-13 seconds & everything is practically instantaneous anyway...

Just a thought

UPDATE:

Legend of Mart just beat me to it -

OP - All of the crap in this thread is only good for 2 things - learning a little bit about SSD & now you know you need to upgrade everything if you want to see the speeds everyone is talking about -

Kinda funny IMHO that nobody checked this earlier.

No, the SF-2281 is awful at reading/writing incompressible data like ISOs and Movies.

ok, but my point is still valid though - the 550MBps claims are sequential data transfers, regardless of controller. i agree that the SF controller is bad at incompressible data, but there are many other controllers...

One thing I havent seen mentioned in here - with his controller/chipset - is it even SATA3 ?

Also, is he getting more than 1 PCIE lane ?

Reason I ask is, all of this ridiculous bickering about speeds would be moot if he is limited by something like that.

For instance, since I have a x58 chipset (original Core i7) I am limited to 400MB/sec due to PCI-Express bandwidth issues.

I have a Vertex 3 in my desktop & cant get better than 400MB/sec - but it matters not since I boot up in 12-13 seconds & everything is practically instantaneous anyway...

Just a thought

you can get better than 400MBps b/c of the SATA2 controller... you're limited to <300MBps

you can get better than 400MBps b/c of the SATA2 controller... you're limited to <300MBps

When you say "you" are you referring to me or people in general ?

Im on a SATA3 controller, but limited to 400MB/sec for other reasons. (PCI-E)

SATA 2 limit is 375MB/sec, but any benchmark I run caps right @ 400MB/sec -

Doesnt bother me a whole lot because computer is so fast

When you say "you" are you referring to me or people in general ?

Im on a SATA3 controller, but limited to 400MB/sec for other reasons. (PCI-E)

SATA 2 limit is 375MB/sec, but any benchmark I run caps right @ 400MB/sec -

Doesnt bother me a whole lot because computer is so fast

Wait, I'm confused. I didn't think PCI-E had anything to do with it?

Wait, I'm confused. I didn't think PCI-E had anything to do with it?

Yep, I dont know if it is this way with AMD, and I dont know if Ivy Bridge is this way either

but I

the SATA3 Controller uses the PCI Express lanes (probably due to them both stemming from the Northbridge.

n the case of x58, this is surely the case.

It is very easy to get caught up in too many details when trying to learn the basics.

Yep, I dont know if it is this way with AMD, and I dont know if Ivy Bridge is this way either

but I

the SATA3 Controller uses the PCI Express lanes (probably due to them both stemming from the Northbridge.

n the case of x58, this is surely the case.

It is very easy to get caught up in too many details when trying to learn the basics.

I had the same problem when I had a first gen i7. I put in a Vertex 3 and then was disappointed by the benchmark. When I upgraded to a 2600K, the benchmarks were spot on with the rating of the drive. Not that it made a huge difference though. :p

Yep, I dont know if it is this way with AMD, and I dont know if Ivy Bridge is this way either

but I

the SATA3 Controller uses the PCI Express lanes (probably due to them both stemming from the Northbridge.

n the case of x58, this is surely the case.

It is very easy to get caught up in too many details when trying to learn the basics.

Does the video card that's using the PCIe slot make a difference? For example, newer cards use a much higher bandwidth than older ones, so older ones should have less PCIe bandwidth used, right? Or does the PCIe allocate a certain amount regardless?

shiven, good question.

It is a pre-determined amount of bandwidth that goes to the SATA controller (I believe it is simply a single, 1x lane)

Newer chips have so many things built into the CPU and these issues dont exist anymore - as Astra mentioned, SB & IB chips have use of a lot more bandwidth.

But like I said, 400MB/sec is pretty darned fast as it is

Isn't that a bit counter-intuitive? One would think that the larger the drive, the more the drive has to read through, so the slower it would be. I guess I don't know enough about the actual process...

Nope. With SSD's larger capacity drives have both more memory chips on their PCB's and usually higher density ones as well. And the benefits that brings are twofold.

Firstly, the controllers of some (most high performance SSD's have this feature) disks have a feature that implements a sort of raid on the memory chips, files are spanned across the drive's memory chips and the more chips it has to span files across the faster reads are likely to be,

The benefit of higher density chips should be pretty obvious really.

And in fact, even with mechanical hard disks, the size of the disk isn't relevant. A 1MB file still takes up 1MB of space whether you store it on a 32GB drive or a 320GB drive. A disk's file allocation table points the operating system to the physical location of the file on the disk so the argument that it would have to search the disk is false.

Nope. With SSD's larger capacity drives have both more memory chips on their PCB's and usually higher density ones as well. And the benefits that brings are twofold.

Firstly, the controllers of some (most high performance SSD's have this feature) disks have a feature that implements a sort of raid on the memory chips, files are spanned across the drive's memory chips and the more chips it has to span files across the faster reads are likely to be,

The benefit of higher density chips should be pretty obvious really.

And in fact, even with mechanical hard disks, the size of the disk isn't relevant. A 1MB file still takes up 1MB of space whether you store it on a 32GB drive or a 320GB drive. A disk's file allocation table points the operating system to the physical location of the file on the disk so the argument that it would have to search the disk is false.

I think what he was saying was not that it has to search for the spot where data is held, its that since there is more space/data on the drive, it takes longer to go to it when directed by the OS...I think.

I think what he was saying was not that it has to search for the spot where data is held, its that since there is more space/data on the drive, it takes longer to go to it when directed by the OS...I think.

It's still a false argument. The physical size of hard drives hasn't changed, and accessing the file allocation table does not significantly differ depending on the size of drive, the factor that impacts that the most is how full the drive is. And even then we're only looking at a difference of little more than a few ms

I think what he was saying was not that it has to search for the spot where data is held, its that since there is more space/data on the drive, it takes longer to go to it when directed by the OS...I think.

Yeah that's basically what I was saying

It's still a false argument. The physical size of hard drives hasn't changed, and accessing the file allocation table does not significantly differ depending on the size of drive, the factor that impacts that the most is how full the drive is. And even then we're only looking at a difference of little more than a few ms

And yeah, I figured there was something flawed with my logic. I need to learn how it actually works...

And yeah, I figured there was something flawed with my logic. I need to learn how it actually works...

Although I'm underplaying the complexity of this a bit, the best analogy I can think of is this.

Think of the hard disk of your computer as like being one massive filing cabinet. The surface of a disk is not solid but is in fact divided up into sectors on which a small amount of data can be stored, if you consider each sector to be a seperate file in your cabinet, the whole of the disk would be equal to a cabinet with loads of files in it. And in the same way you would identify a file in your cabinet by the shelf it's on and the number on the file, the same is true of each cluster on the computer's hard drive. And as your disk fills up the clusters get more and more used.

Now think of the file allocation as like being a massive index, as the index will tell you what paperwork is stored in what file and in what drawer, the file allocation table's function is very similar, it is essentially a database of what files are stored on a disk. So when, for example a program writes a file to sectors 1101, 1102, and 1103 an entry will be created in the file allocation table to tell the operating system what sectors this file is on. As you can imagine if the file allocation table weren't there the OS would have to search the disk sector by sector every time it wanted to access the file which would be extremely cumbersome. The file allocation table allows the OS to simply spin the disk up, move the head directly to the sectors that the file allocation table says the file was written to, and read the data back in the same way the index in your file would direct you to the shelf and number of folder you wanted. And that is why performance degrades as a disk fills up, as the amount of entries in the file allocation table increases, it obviously takes marginally longer to read them all (although again the differences are very small)

Although SSD's don't have any moving parts so they don't have to spin up, the principle is the same except the data is stored in a one of millions of flash cells rather than one of millions of physical sectors.

I hope that helps you somewhat

Well, I got my SSD installed and running, and I'm sad to report that I'm less impressed with the benchmark than I expected. It is noticeably faster than my WD Raptor though, so definitely an improvement. I realized that since I transferred over my existing imagine (as opposed to a fresh install), the drive wouldn't have as good as results in CDM as a completely empty drive, but nonetheless, I thought they'd be better than this (see attached).

Few PC Specs:

X4 955 @ 3.4

4GB 1600MHz RAM

(SSD, obviously), which is connected through SATA III. It's the only drive connected ATM.

Thoughts on what could be going wrong here?

post-157925-0-98119600-1338604601.jpg

Well, I got my SSD installed and running, and I'm sad to report that I'm less impressed with the benchmark than I expected. It is noticeably faster than my WD Raptor though, so definitely an improvement. I realized that since I transferred over my existing imagine (as opposed to a fresh install), the drive wouldn't have as good as results in CDM as a completely empty drive, but nonetheless, I thought they'd be better than this (see attached).

Few PC Specs:

X4 955 @ 3.4

4GB 1600MHz RAM

(SSD, obviously), which is connected through SATA III. It's the only drive connected ATM.

Thoughts on what could be going wrong here?

Don't worry about synthetic benchmarks. Even low end SSD's should still provide much better system responsiveness than mechanical hard drives so I'd just ignore what the benchmarks are saying and focus on the real world performance.

Don't worry about synthetic benchmarks. Even low end SSD's should still provide much better system responsiveness than mechanical hard drives so I'd just ignore what the benchmarks are saying and focus on the real world performance.

While quite true, shouldn't I at least get something near the advertised results in benchmarks? While the drive is still much faster than my mechanical one, it bugs me that it isn't even close what I thought it would be.

** And yes, most importantly: I've updated to firmware v1.4.

On Monday, I'll run through those same benchmarks on my Vertex 4 and post the results. I'll also attempt to run them both in Win7 and Win8 Release Preview, which I just installed on Friday night. It should be interesting to see any differences between the two operating systems. Right now I can say that Win8 definitely boots faster than Win7, which is pretty impressive considering how fast Win7 already boots-up.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • OpenAI's new GPT-5.5-Cyber tops Claude Mythos 5 in vulnerability benchmark by Pradeep Viswanathan OpenAI today announced a major expansion of Daybreak, a cybersecurity initiative designed to help defenders find, validate, and fix software vulnerabilities earlier in the development process. The availability of powerful AI models has definitely changed the cybersecurity landscape by making vulnerability discovery much faster. However, the bigger bottleneck for the industry is now patching those vulnerabilities. Impacted software teams need to validate the discovered issues, understand their impact, develop fixes, test them, and deploy patches. Back in March, OpenAI launched a preview of Codex Security, which uses agentic reasoning with automated validation to discover high-impact issues and actionable fixes specific to the codebase. Since then, it has scanned more than 30 million commits across over 30,000 codebases; more than 70,000 findings were marked as fixed by human reviewers, while over 500,000 findings were automatically determined to be fixed. Now, OpenAI is releasing an updated Codex Security plugin that can run deep scans, review recent code changes, generate security reports, trace attack paths, validate findings, and create codebase-specific patches for human review. It can also triage findings from existing scanners, advisories, bug bounty reports, and ticketing systems. OpenAI says the plugin can export results to vulnerability management systems and integrate with workflows using SARIF files, CodeQL queries, the Codex CLI, and the Codex app. Back in May, OpenAI announced the preview of GPT-5.5-Cyber, a new model built on top of the recently released GPT-5.5, designed for specialized cybersecurity work. Today, OpenAI launched the full version of GPT-5.5-Cyber through a limited release for verified defenders. On CyberGym, GPT-5.5-Cyber scored 85.6%, compared with 81.8% for GPT-5.5 and 83.8% for Claude Mythos 5. It also scored 39.5% on ExploitGym, compared with 25.95% for GPT-5.5, and 69.8% on SEC-bench Pro, compared with 63.1%. OpenAI also announced the new Daybreak Cyber Partner Program, which will allow security vendors and service providers to use GPT-5.5 with Trusted Access for Cyber in their products and services. Accenture, Akamai, Cisco, Cloudflare, CrowdStrike, IBM, Palo Alto Networks, Proofpoint, SentinelOne, Wiz, Zscaler, and others were listed as initial partners for this program. OpenAI is also launching Patch the Planet with Trail of Bits, HackerOne, Calif, researchers, and maintainers. More than 30 open-source projects have committed to participate, including cURL, Go, Python, Sigstore, and pyca/cryptography.
    • AMD confirms 26.6.2 FSR driver breaks on many Windows PCs by Sayan Sen Earlier today AMD released a major graphics driver update as it brings support for FSR 4.1 to Radeon RX 7000 series GPUs. The new update, version 26.6.2, also brings support for Assassin's Creed Black Flag Resynced and more. And while the driver technically supports Windows 10 version 21H2 and newer, the tech giant has confirmed that there is a major issue with the new driver on non-Windows 11 PCs as it fails to launch properly on such systems. The error message says, "The version of AMD Software that you have launched is not compatible with your currently installed AMD graphics driver." Therefore on the surface it looks like a compatibility problem. AMD has also confirmed that the device manager will display the yellow bang or yellow exclamation sign alongside your GPU under the Display adapters dropdown. Here is what the Radeon team's official advisory recommends to affected users: "Users Running Windows 10 and AMD Software: Adrenalin Edition 26.6.2 May Encounter Yellow Bang in Device Manager Affecting AMD Radeon RX Series Graphics ... Our Engineers are currently investigating this issue and will provide a fix once it is available. Affected users may revert to AMD Software: Adrenalin Edition 26.6.1 as a temporary workaround." As such you should revert back to the previous 26.6.1 driver which was released earlier this month. In case you were looking to play Assassin's Creed Black Flag Resynced and DOOM: The Dark Ages | Revelations you will probably have to wait a while if you want the driver to support those games officially. You can find the support article here on Microsoft's website.
    • https://uupdump.net/selectlang...7829-4524-978d-7b5fe79263e3
    • A McDonald's restaurant uses about 1.5 to 2 million gallons of water per year for operations like food preparation, cleaning, and restrooms. That is a lot less than the 2,083 gallons of water per megawatt hour mentioned above.
    • Turbo Pascal Original authorAnders Hejlsberg (at Borland) DeveloperBorland Release20 November 1983; 42 years ago[1][2] Operating systemCP/M, CP/M-86, MS-DOS, Windows 3.x, Classic Mac OS PlatformZ80, x86, 68000, PC-98 https://en.wikipedia.org/wiki/Turbo_Pascal It was the one language I actually learned to program in.   I wasn't very good at it and never used it at work.    If anyone has any personal Turbo Pascal stories or personal accomplishments using it, please take a moment to share.   Thanks. Peace
  • Recent Achievements

    • Week One Done
      Almohandis earned a badge
      Week One Done
    • Rookie
      dorf went up a rank
      Rookie
    • First Post
      mike_rumble earned a badge
      First Post
    • Dedicated
      tuben earned a badge
      Dedicated
    • Week One Done
      mnsgroup earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      505
    2. 2
      +Edouard
      208
    3. 3
      PsYcHoKiLLa
      100
    4. 4
      Michael Scrip
      88
    5. 5
      neufuse
      71
  • Tell a friend

    Love Neowin? Tell a friend!