S9 flow skew bug... Anyone else seeing this?

[Muse-Inc]

Great minds think alike

[alterego61]

I was talking with SanDisk tech support to day and that was their recommendation...
Nord

Well, the card manufacturer would say that. Class 10 cards are even more expensive than class 4 or class 2.

It would make no sense at all that hyper-spec cards like this would be required to make the s9 work properly. I guess there's no harm (other than cost) in testing class 10 cards, but with what we now know about how the s9 works I really doubt card speed is the cause for or the solution to this issue. The skews we see are a reflection of different timestamps being present in the headers of each of the set of associated data files for the same mask event. The header timestamps are written as soon as the machine is started at the beginning of the mask event. A difference of a few milliseconds in card write speed could not account, of itself, for the skews of 20 seconds or more in header timestamps, or the increases in skews from one day to the next, that we see in many users' data. Something cumulative is going on, and something which adds up to many seconds, not a few milliseconds.

The other working theory about removing the card too soon at the end of a prior mask event corrupting the data, or some other yet to be identified cause seem far more likely.

[alterego61]

Another "hit and run" message......

When the obvious gets lost in the noise created by power posters, short statements of real fact are useful reminders about the actual situation.

As others here have posted, the fact that people who list the s9 as equipment may not have reported skews does not mean that they don't have them, they may simply be unaware of them. They may not be using ResScan, or they may not have noticed or not know how to identify the skews in their data.

"Noise", "power posters" and "actual situation" are not defined. Your "short statement of real fact" is just a subjective personal opinion like most others here. What appears obvious to you may or may not be correct, and whether your opinion is useful or not is better judged by the other members of the forum, not by you.

Bill, it appears that you are knowledgeable and intelligent and personally I find the content of some of your posts useful and interesting even if the language is occasionally a bit overbearing. In this case however I found your contribution to be neither helpful nor insightful. That is just my opinion; others may feel differently.

[billbolton]

even if the language is occasionally a bit overbearing.

Too close for comfort it seems

[dave21]

A lot seems to have happened since I've been away this week....

I suggest everyone tries to bury the hatchets and continue to investigate the skewing with testing. All of us have our own personal opinions as we're all human and different and that's fine, but let's try not to impose our opinions on others. Everyone should be willing to make up their own mind on what's correct procedure and what's not.

Back to the subject in question.....
It looks like we might have a viable suggestion from ResMed now on why the skews are happening. For the most part I do eject my SD card from the S9 <5 mins after powering the S9 off, and that might be the cause of the skews but I also know there's some times I wait nearly 10 mins because I go for a bathroom break before ejecting the card. Hopefully ResMed are correct and it's possibly user error (not knowing that we can't eject the card soon after power off).

I will probably look to reset my S9 and format the card tonight and remove the card 10 mins after powering off the S9 for the next couple of weeks using my 16gb Sandisk SD card and see if that makes a difference.

Bill, bearing in mind you're in the camp of not seeing any skews from what you have previously said on this topic, do you read your data in ResScan each day, bi-daily, weekly, bi-weekly or rarely? When you eject your card to read it in ResScan how long do you leave it after power off of the S9?

Thanks
Dave

[billbolton]

from what you have previously said on this topic, do you read your data in ResScan each day, bi-daily, weekly, bi-weekly or rarely? When you eject your card to read it in ResScan how long do you leave it after power off of the S9?

viewtopic/p475074/viewtopic.php?p=468553#p468553

[DreamDiver]

from what you have previously said on this topic, do you read your data in ResScan each day, bi-daily, weekly, bi-weekly or rarely? When you eject your card to read it in ResScan how long do you leave it after power off of the S9?

viewtopic/p475074/viewtopic.php?p=468553#p468553

billbolton, alterego61, I agree that buying a class 10 card seems like overkill. They didn't supply us with a class 10 card - suggesting that this is not a prerequisite. Apparently it has more to do with the need for faster housekeeping - CRC, whatever that is - within the SD card itself. Unfortunately, I don't know of any way to test for this, and I don't entirely understand the concepts involved.

I get the impression that it is entirely possible only a very few of us have the skew problem. I'd rather not spin my wheels by constantly trying to fix what I can't. I know with all current combinations of hardware and software, all attempts to thwart skew are for naught. I'm just going to keep watching it for now. I'm also going to assume the problem is with the SD card, since that's what ResMed says. I'm going to wait until I hear from ResMed or SanDisk as to the correct card to buy and where.

At this point, I'm confused. I'm also sorry to see that there seems to be some friction caused by the question of skew. I think I'm going to step back and take a break from all of this.

Someone may have explained the CRC thing in a previous post on this or another thread clearly. If so, could someone please point me to it? I'd be grateful.

[alterego61]

DreamDiver, if you type CRC into the search box at the top left of the page you will find the threads you are looking for.

[Nord]

Some housekeeping and some "catch up" of my own to do:

I have been collecting serial numbers/ lot numbers of S9 data for a short while... I am still collecting as some members have not responded yet.
"So far... 11 machines reporting they had checked: 8 reporting skew issues... 3 reporting none seen"
There is some pattern that I have seen but it is a very small sample... so far. Oddly it is not the latest serial numbers that have no skew... it is related to "Lot" numbers and perhaps component suppliers. I can't say at this point.


At the risk of making this a longer post but not wanting to increase my "power" numbers... there are some unrelated thoughts.

1. I, too do not see the CRC and Registry Issue to be very valid...
Since some of these machines that have ResMed cards, have no skew issues... they do not have Class 10 or perhaps even genuine Class 2 SD cards.
I think ResMed's statement about "small number of SD ResMed cards that have slower speeds" is probably related to a supplier issue based on low price as opposed to Card Design issues.
I do NOT see value in trying out higher Class SD cards especially Class 10.

2. I am following a simple pattern of care in collecting data on my own S9 and have good results so far, but only 7 Mask Sessions... No skew seen yet...
I wait 5 minutes (as a safe amount of time for writes) before removing card from the S9.
I do not lock/ unlock SD card. I DO eject the SD card after use in ResScan.
I shut the S9 down once per day for at least several minutes and replace the card before powering on.
I am using the ResMed original card that has been formatted with the SD Association software (FAT 16).

3. While thinking over this issue, I went into ResScan 3.10 and looked again at the Examples Group of patients...
The S9 "patient" has 3 days of data and 3 mask sessions which SHOWS SKEW of +0 sec; +3 sec; and +1 sec...
ResMed only show 3 days and 3 mask sessions which is much less than any other "patients" in their Example Group.
The S8 AutoSet Vantage II in the same Example Group, shows SKEW values for 1 minute and more.
Seems to point to a firmware issue or ResMed's "acceptable" variables...


As an aside to billbolton:
I respect your knowledge in many areas and I do look forward to your posted experiences...
I also respect your database of knowledge related to CPAP issues... particularly ResMed.
I generally do not care for your delivery of your Point of View...
But that's who you are... I accept that.
I Do Not accept your point of view that you have The Only "right answers" and are only too willing to tell people that...
I, too have my faults, so I will continue to Post when I see that "creep into" your posts...
Cause I find it just as hard to control who I am... as you do... its only fair...

Cheers
Nord

[alterego61]

even if the language is occasionally a bit overbearing.

Too close for comfort it seems

What do you mean Bill?

[DreamDiver]

DreamDiver, if you type CRC into the search box at the top left of the page you will find the threads you are looking for.

and...

I, too do not see the CRC and Registry Issue to be very valid...

Part of the problem is that the CRC issue is being confused with card speed. Apparently, it's not about speed. It's about the card's housekeeping methods. I mistakenly misquoted ResMed when I originally thought they were talking about card speed. Card Class apparently has little to do with this issue. It's about card housekeeping. There's something about 100ms vs. 250ms -- I'm not sure if they're talking about how long a card must or may wait between writes/reads, or how long the machine can wait between cache dumps. I don't know whether it's better to have a card with 250ms housekeeping or 100ms housekeeping. For all intents, it could be either. The ResMed response has been a little challenging for me to grasp. The responses within the thread are also difficult for me to grasp. I have been searching for a primer on exactly what housekeeping rules for SD cards are about. This looked interesting, but again, out of my scope of immediate understanding. As Nord points out below, perhaps this is more of a firmware issue, as previously suspected, than an SD card issue. I'm just trying to understand the housekeeping issue myself before ruling it out entirely.

...While thinking over this issue, I went into ResScan 3.10 and looked again at the Examples Group of patients...
The S9 "patient" has 3 days of data and 3 mask sessions which SHOWS SKEW of +0 sec; +3 sec; and +1 sec...
ResMed only show 3 days and 3 mask sessions which is much less than any other "patients" in their Example Group.
The S8 AutoSet Vantage II in the same Example Group, shows SKEW values for 1 minute and more.
Seems to point to a firmware issue or ResMed's "acceptable" variables...

DOH!

[alterego61]

Data are written to the cards by the S9 though, not by our computers. Do we know what O/S the S9 runs? It is almost certainly not Windows.

Almost certainly not. My bet is a home-grown realtime OS, though it could be one of the commercial lightweight RTOSes like QNX.

In any case it is possible to make lower level calls to write to a storage medium at a more granular level even if you are running a higher level O/S like Windows or Linux so if this is the source of the problem it would be an error in the way that ResMed decided to write to the cards rather than a fundamental difficiency in the storage medium or how it interacts with higher level operating systems.

Well, when you're writing small, sporadic data chunks any OS is going to perform the actual writes on a sector (512-byte) basis. The larger clusters are for file allocation and keeping the copies of the FAT in memory small. In other words, the cluster size determines how the file is laid out on the disk, while the actual movement of data is determined by the physical device.

In any case, all that business about cluster sizes is determined by the FAT filesystem, regardless of OS.

ken

Ken, I'm still trying to get my head around how SD cards work. This description (from Wikipedia) explicitly describes how embedded systems normally interface with SD cards:

"For the most part, the lack of a complete, open SD specification mainly affects embedded systems, since desktop users generally read SD cards via USB-based card readers. These card readers present a standard USB mass storage interface to memory cards, thus separating the operating system from the details of the underlying SD interface. However, embedded systems...usually access SD cards directly, and therefore complete programming information is necessary."

[alterego61]

DreamDiver, regarding your comments on card speed and 100 ms vs. 250 ms, I don't know much yet about the details of how SD cards work but I found this document which helps:

http://www.sdcard.org/developers/tech/s ... r_Spec.pdf

Section 4.5 describes how CRC (Cyclic Redundancy Code) is used, and section 4.6 describes error conditions, including timeout errors.

As I understand it, the text below from section 4.6 describes the conditions under which a card may suffer a timeout after 100 ms or 250 ms has passed and a write command has not yet (been signaled as having) completed. Note that a standard capacity card is defined in this document as up to and including 2GB and a high capacity card as anything from 2GB to 32GB.

I'm not an expert in programming realtime embedded devices but it would seem to me that the s9 program code should allow for timeout error conditions and handle them without corrupting the data.


4.6.2 Read, Write and Erase Timeout Conditions

A card shall complete the command within the time period defined as follows or give up and return an
error message. If the host does not get any response with the given timeout it should assume that the
card is not going to respond and try to recover (e.g. reset the card, power cycle, reject, etc.).

4.6.2.2 Write
For a Standard Capacity SD Memory Card, the times after which a timeout condition for write operations
occurs are (card independent) either 100 times longer than the typical program times for these
operations given below or 250 ms (the lower of the two). The R2W_FACTOR field in the CSD is used
to calculate the typical block program time obtained by multiplying the read access time by this factor. It
applies to all write commands (e.g. SET(CLR)_WRITE_PROTECT, PROGRAM_CSD and the block
write commands).

A High Capacity SD Memory Card indicates R2W_FACTOR as a fixed value.
Maximum length of busy is defined as 250 ms for all write operations. The host should use 250 ms
timeout (minimum) for single and multiple write operations rather than using R2W_FACTOR.

[Nord]

DreamDiver, if you type CRC into the search box at the top left of the page you will find the threads you are looking for.

and...

I, too do not see the CRC and Registry Issue to be very valid...

Part of the problem is that the CRC issue is being confused with card speed. Apparently, it's not about speed. It's about the card's housekeeping methods. I mistakenly misquoted ResMed when I originally thought they were talking about card speed. Card Class apparently has little to do with this issue. It's about card housekeeping. There's something about 100ms vs. 250ms -- I'm not sure if they're talking about how long a card must or may wait between writes/reads, or how long the machine can wait between cache dumps. I don't know whether it's better to have a card with 250ms housekeeping or 100ms housekeeping. For all intents, it could be either. The ResMed response has been a little challenging for me to grasp. The responses within the thread are also difficult for me to grasp. I have been searching for a primer on exactly what housekeeping rules for SD cards are about. This looked interesting, but again, out of my scope of immediate understanding. As Nord points out below, perhaps this is more of a firmware issue, as previously suspected, than an SD card issue. I'm just trying to understand the housekeeping issue myself before ruling it out entirely.

Hi DD

Yes it is completely separate issue from writing data... it is about the proprietary differences in how the SD card goes about its business. That "housekeeping" speed is not specified by the SD Assoc. who controls some of the "differences" in the cards so that they maintain some standards that work in cameras, computers etc. They control physical sizes, Classification of Speeds for data writing etc but they do NOT control all factors.

The Assoc is similar to the way a Racing Car organization controls many of the values that racing teams use. Teams still have different engines, tires, set-ups etc and they have different capabilities because of that... no matter strategies or drivers... some are inherently faster. The Classification would be, just like say, Formula One and many different speed cars race within that classification.

I'll send you some links for reading if you're up for it... it might help you get to sleep some night.

The Class 10 card that SanDisk Techie recommended, was because it was an easy answer for him... he didn't know the right answer and felt that recommending the best card they had would be a safe answer... and probably one that SanDisk would like him to choose.

Nord

[alterego61]

The most popular theory right now for the source of the skew problem is removing the SD card too soon before all data have been written to it.

I found it interesting that the open specification for SD cards (http://www.sdcard.org/developers/tech/s ... r_Spec.pdf) omits the content for the section for hot insertion and removal: "This section is a blank for the Simplified Specification".

In the SanDisk product manual (http://www.cs.ucr.edu/~amitra/sdcard/Pr ... rdv1.9.pdf), the following section indicates that hot insertion/removal of the card should be handled:

"Hot insertion and removal are allowed. The SanDisk SD Card will not be damaged by inserting or removing it into the SD bus even when the power is up:
• The inserted card will be properly reset also when CLK carries a clock frequency fPP.
• Data transfer failures induced by removal/insertion should be detected by the bus master using the CRC codes that suffix every bus transaction. "