Skew flow bug may be due to SD card speed...

[DreamDiver]

There is a possibility skew bug may be due to the read/write speed of the SD card. To that end, I have created a benchmark comparison for three cards: the 1GB SD card I got from ResMed, a 2GB SD card I bought online (Kingston brand, unclassed), and a 4GB SD card (PNY brand, class 4). I used Aida32's hard-drive benchmarking plugin to try to get some numbers, posted here. I'm not sure I understand all the numbers, but I've faithfully copied them and charted them so we can look together and make an assessment. I'd be grateful for anyone's reflections on whether my new SD cards will work based on comparison with two other known quantities: the ResMed card which we are assuming doesn't function for this experiment, and the PNY Card which we know should be far above the needs of the S9 in terms of write speed.

I should note that last night's data included no one-second skew at the beginning, so that may be a good thing.

[Nord]

I like the thinking... this sounds right to me DD...

I have become more pointed towards the cards as opposed to the S9 and am using ScanDisk 2 Gig that I am testing. No skews 3 days of data. I was going to change to an empty card every 4 days. Not scientific but I was hoping to find a cure by accident.

I'm guessing that the cheap ResMed card slows down even more as it gets more data loaded on... just like a full hard drive or full memory. That would account for the gradually worse skew figures.

Nord

[bailachel]

Dreamdiver, In your intro to the card comparison data you say "According to ResMed, my original SD card may be too slow, causing the bug."

Did they say why they are providing cards that might be too slow?

[DreamOn]

Arizona-Willie's been using the S9 for just over a month. He's used only the ResMed SD card to date and apparently has not had any skewing: viewtopic/t51150/viewtopic.php?f=1&t=51 ... 87#p469887. He has had some problems getting the card to read on the computer end. He does not unplug the S9 machine. He discards duplicate data when downloading the data into ResScan. I don't know if he downloads detailed data for only one session (24-hour period from noon to noon) at a time, or chooses to download multiple detailed data sessions each time.

Since he's one of the few that hasn't had the skewing problem, you may want to see what/if he's doing anything different than those who have had problems. I don't recall if there's anyone else who's used the S9 for a while and hasn't seen the flow data skewing, but if so they may be able to contribute some valuable information.

Good luck! I look forward to hearing the results of everyone's testing. I'm interesting in purchasing an S9, but I plan to wait until this is figured out.

[dave21]

DreamDiver, I'm not too sure it's related to SD card speed. Here's why in my experience...

1. Original ResMed card didn't skew for 80% of the time for me but did skew 20% of the time
2. My new 16gb ScanDisk SDHC didn't skew for 90% of the time but has skewed for 10% of the time

So I have seen the skew both on the original ResMed card and also the newer faster SanDisk cards.

For me I'm not seeing any skewing and for the past few days I've also not been power cycling the S9 either.

Thanks
Dave

[DreamDiver]

Resmed suggested that I may have gotten a card with bad write times. Some of the earliest units used these cards, but they were replaced with faster cards when the problem was found out. Arizona-Willie probably has a card with good write speed.

Fragmentation and Speed

The memory of a card is divided into minimum memory units. The host writes data onto memory units where no data is already stored. As available memory becomes divided into smaller units through normal use, this leads to an increase in non-linear, or fragmented storage. The amount of fragmentation can reduce write speeds so higher SD card speeds help compensate for fragmentation.

The SD Association has specified operating conditions for SDHC memory cards to guarantee the minimum speed according to the card's speed class. Class logos are provided to help identify cards that comply with these specifications.

Smaller cards (1GB) are more likely to show fragmentation earlier. 16GB cards have larger swaths of open space longer, hence take longer to show the problem. Cards with no classification on them may be too embarrassingly crummy to even classify with regards to guaranteed write speed. Class 2 cards from many manufacturers are notorious for not really being class 2.

AFAIK some flash disks have really bad write performance (esp. cheap brands). So if you measure the write speed of your application (including the time required for fsync), what do you get? It might easily be in the order of very few megabytes per second - just because the hardware doesn't do better.

Also, apparently writing can be much slower if you write many small blocks instead of one big block (the flash disk might only get about 10 writes per second done, in bad cases). This is probably something that can be mitigated by the kernel buffer, so using fsync frequently might slow down the writing...

Btw. did you measure write performance on FAT32? I would guess it is about the same, but if not, maybe there's some optimization still available?

With a video capture system using an SD card, there are three possibilities as to what can happen with the data. It can either drop frames or it can add the frames and skew the data with regards to audio, or the card is fast enough to write both with no skew or dropped frames. High-resolution flow data is analagous to video, with detailed data being analagous to its associated audio. In our case, flow "frames" are not dropped, but instead are skewed with regards to detailed data.

That's why formatting the card and starting over works - at least for a few days. An empty card offers more space for unfragmented writes. That the data is concatenated to the end of the file is what makes things difficult. As evidenced in the two second data begin-and-end situation in this post, the S9 is probably concatenating data to seven files every two seconds. Concurrently, the flow data is being written to one *BRP.edf file on the SD card many times per second. The machine wants to write the data linearly, but when it bumps into a sector that's already written by another file, it has to jump and find another clear sector and link that data to the file fragment it left in the previous non-contiguous sector. Writes are faster when you can do them contiguously. The more files on the disk, the higher the necessity for random writes. Random writes take more time than linear writes.

The implication is that we have 1GB cards because it's less expensive to provide an SD card with more space than appears necessary to accommodate random writes than it is to provide a smaller card with a guaranteed minimum write speed. That's also a possible indication as to why flow data is erased on a seven-day rotating interval.





In the above charts, write speeds are shown for the ResMed 1GB (unclassified), a Kingston 2GB (unclassified), and a PNY 4GB (Class 4) cards. The minimum write speeds are what we need to look at. Averages are nice, but when data skews, averages aren't going to help us. It's the slowest measured speed that means more. Though the 2GB card shows it's better at linear writes than the 1GB card, It's possible that my 2GB cards will end up being worse as the card fills up with data, if the random write benchmarks appear to be correct. While the benchmarks showed an average for 3.93MB/s for the 4GB card, even that class 4 card had a minimum random write speed of 2.21 MB/s. Sooner or later, that minimum write random speed is going to show problems if it's lower than the threshold of the necessary write speed of the S9.

I'm going to continue using the 2GB card until I see skew. Then I'm going to try my class 4 SD card to see whether write speed really is the problem.

Ostensibly, the class 4 card should solve the problem entirely. If so, then class 2 cards or less are probably contraindicated for use with the S9, and class 4 or class 6 cards should be used instead. If not, then we can be more sure that the flow skew is a bug in the S9 firmware and not a card speed issue.

The only thing I can suggest is that those who are interested should download Aida32 and check their card's write speeds. Please note: Aida32 destroys all data on your card so back it up first and save your data to ResScan 3.10 before checking your write speeds.

[DreamOn]

Resmed suggested that I may have gotten a card with bad write times. Some of the earliest units used these cards, but they were replaced with faster cards when the problem was found out.

That's interesting.

I look forward to everyone's reports. It sure would be nice if the SD card is responsible for the skewing, as that can be easily remedied once it's determined what does work.

[dave21]

That's why formatting the card and starting over works - at least for a few days. An empty card offers more space for unfragmented writes. That the data is concatenated to the end of the file is what makes things difficult. As evidenced in the two second data begin-and-end situation in this post, the S9 is probably concatenating data to seven files every two seconds. Concurrently, the flow data is being written to one *BRP.edf file on the SD card many times per second.

One thing we haven't thought about is write-back cache. In Windows and many other operating systems, write-back cache is there to ensure blocks of data don't get dropped from writing, e.g. because the OS / card writer can't keep up with the write method. This involves having a cache chip that caches the data and then sends it at a slower more acceptable rate to the SD card. It also has the CRC Checking so that if something doesn't get written under error control, it will halt the flow of data and re-write the data. Now it's entirely possible that the ResMed OS doesn't incorporate write-back cache (it's usually more expensive to have this on the motherboard), if ResMed don't, then it's possible that the S9 is getting its knickers in a twist some times, and slower SD cards I guess could be compounding it (or SD cards with bad FAT 32 tables). Also bear in mind that this is ResMed's first SD card machine that some cut backs may have occurred like removal of write-cache chips or even been overlooked.

If it is down to the SD card (which I still don't know that it is), then I would expect to continuously see it on the same SD card, but I see it very rarely. If it's down to this, then it could be a FAT 32 table corruption thats slowing the SD card down, or badly written data to the table.

The only thing I can suggest is that those who are interested should download Aida32 and check their card's write speeds. Please note: Aida32 destroys all data on your card so back it up first and save your data to ResScan 3.10 before checking your write speeds.

One thing to bear in mind is that if other people test using Aida32 they may get different results even if they borrowed your SD card because each PC/device is going to handle the writes differently depending on the amount of RAM and write-back cache they have on-board. Many of the SD card testing sites always use the same machine and same card reader to ensure they get consistent results. If you have the ability to test some other cards it would be interesting to see which ones seem to be better and which ones actually work better, but that could become expensive buying in cards.

Thanks
Dave

[DreamDiver]

...
One thing we haven't thought about is write-back cache.
... each PC/device is going to handle the writes differently depending on the amount of RAM and write-back cache they have on-board. Many of the SD card testing sites always use the same machine and same card reader to ensure they get consistent results...

Unfortunately, Aida32 didn't provide buffered write benchmarking, so write-back cache could not be tested.

With regards to the new 2GB SD cards I bought from Buy.com through ebay: The night prior there was no skew - not even the one-second thing at the beginning. All data lined up precisely, except for the two-second subtract on the detail data at the end. I got a one second delay in my first mask event of last night and a two second delay in my second mask event. I also had a huge number of events compared to usual, but that's probably unrelated. Flow still ends on the same numeral that it begins on. Detailed data still end two seconds less than the starting numeral.

I have an SD card that is a class 6, but it's 16GB and half full of video data right now. This weekend after the Atlanta meeting, I'll pop by Fry's and see what they've got on sale in the SD card department. They usually have at least one decent bargain every time I go there.

[alterego61]

First time poster here, just upgraded to S9 Auto. I'm new to both the machine and the software but I'm fairly computer literate so maybe I can contribute to this discussion. Please can you explain in simple terms how to identify if the high-res data in ResScan 3.10 is skewed - all being well I'll have my first S9 data tomorrow!

I'm using a 16GB class 4 SD card from the get-go so with any luck card speed should not be an issue for me.

Cheers.

[DreamOn]

First time poster here, just upgraded to S9 Auto. I'm new to both the machine and the software but I'm fairly computer literate so maybe I can contribute to this discussion. Please can you explain in simple terms how to identify if the high-res data in ResScan 3.10 is skewed - all being well I'll have my first S9 data tomorrow!

I'm using a 16GB class 4 SD card from the get-go so with any luck card speed should not be an issue for me.

Cheers.

Hi, alterego61. Welcome to the forum!

To understand what to look for in ResScan 3.10, I suggest you start with this thread: viewtopic.php?f=1&t=50578&st=0&sk=t&sd=a. There are quite a few other threads that have been discussing this too, so you may want to do a search for "S9 data card" or "S9 skew" or similar. I'm sure the others will come along here to explain more, but that'll get you started in learning what to look for.

Dave21 has compiled a lot of very helpful information on many aspects of xPAP therapy here: http://www.osahelp.com/. There are some great screenshots of the software there.

I hope that your therapy goes well with the S9 Auto. Reports are that it's a great machine!

[bigk]

Dumb question - how do you identify the class of the card?

[billbolton]

High-resolution flow data is analagous to video, with detailed data being analagous to its associated audio.

I don't know where you got that from, but there is nothing at all that I can see in the nature of the overall S9 system which would suggest it has any applicability at all.

An empty card offers more space for unfragmented writes.

Fragmentation is not an issue for solid state media, which has an access time characteristic which is essentially constant.

Random writes take more time than linear writes.

For the nature of the data set, and the time series involved it, this is a meaningless assertion.

My ~1GB Resmed branded SD card currently has ~23MB of data written to it, which represents a couple of weeks of use.

Cheers

Bill

[DreamDiver]

Dumb question - how do you identify the class of the card?

If the card has no class on it (sometimes very small - get out your magnifying glass) it is likely class 2 or less. This is pesronal observation. YMMV.
http://www.sdcard.org/developers/tech/speed_class/

High-resolution flow data is analagous to video, with detailed data being analagous to its associated audio.

I don't know where you got that from, but there is nothing at all that I can see in the nature of the overall S9 system which would suggest it has any applicability at all.

An empty card offers more space for unfragmented writes.

Fragmentation is not an issue for solid state media, which has an access time characteristic which is essentially constant.

Random writes take more time than linear writes.

For the nature of the data set, and the time series involved it, this is a meaningless assertion.

My ~1GB Resmed branded SD card currently has ~23MB of data written to it, which represents a couple of weeks of use.

Cheers

Bill

Merely a theory. I'm trying to wrap my head around why write or access times would be so important. If I'm wrong, okay. If you are suggesting it's not the card's fault, great. That could put an end to this line of query. If you are suggesting it's the card's fault for other reasons, great too. I'd really like to hear your thoughts either way. What do you think is causing the skew?

[alterego61]

Fragmentation is not an issue for solid state media, which has an access time characteristic which is essentially constant.

Bill, it depends on how you define "essentially constant", but your statement is not strictly speaking correct:

"The memory of a card is divided into minimum memory units. The host writes data onto memory units where no data is already stored. As available memory becomes divided into smaller units through normal use, this leads to an increase in non-linear, or fragmented storage. The amount of fragmentation can reduce write speeds so higher SD card speeds help compensate for fragmentation."

"With the new Speed Classes, the host product has the option to check the fragmented state of the card and immediately calculate the write speed in each part of the card. The host can then determine where best to write the data according to its speed requirement."

-- from the SD card assocation link above (http://www.sdcard.org/developers/tech/speed_class/)

For some high-speed applications like video that speed requirement can be an issue. I somehow doubt that it is for the S9.