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

[Nord]

Hi alterego

Just some random thoughts... I did get a pretty good sleep last night ( 6 instead of 2 or 3)
Something here might jog your thought/ creative process

Since all the files are timestamped at the time they are created... and should, in theory, all files should be created at the same time (for no skew).

Could it be congestion for the writer accessing the SD or bogging down the cache to keep up with all the files... not so much writing access to the Hi Rez 25 Hz data... but trying to do all the 2 Hz data at the same time.

That could mean speed of the card, speed of the writer, speed/ size of the cache could play a part ???

BTW alterego: I'll start a thread to try to collect machine info.

Thanks
Nord

[DreamDiver]

Widening detailed skew seen on the last 24 hour session. Night of April 15.
Start and Stop differences in seconds by Mask Event
(Pressure time minus Flow time):
First Event: Start: 6 | Stop: 4
Second Event: Start: 6 | Stop: 4
Third Event: Start: 6 | Stop: 4
Fourth Event: Start: 8 | Stop: 6

No anomalies other than skew.

[Nord]

Repeat of Info to keep Thread in position:

Still Skewing Progressively...

Apr 13th... 1 - 7 Mask Sessions - Skewing up to 3 seconds... Missing No Data... Flow now starts on Odd Seconds...

Apr 14th... 8 - 20 Mask Sessions - Skewing up to 17 seconds... Missing 50 seconds and 46 seconds... Flow now starts on Odd Seconds... 1 Hypopnea out of position

Apr 15th... 21 - 23 Mask Sessions - Skewing up to 21 seconds... Missing 45 seconds and 43 seconds and 41 seconds... Flow now starts on Odd Seconds... 1 OA severely out of place

Nord

[Nord]

I have not had as much time as I would have hoped tonight to look at data, but here is an interesting set of files from Nord (sorry this doesn't format too well without a table):

Timestamps
File Type Sampling Freq Sample Interval Header Rescan Start/Finish
20100415_045646_SAD.edf Oximetry 1 Hz 1 sec 04.57.12 (no data) (no data)
20100415_045646_PLD.edf Pressure/Leak 0.5 Hz 2 sec 04.57.05 04:57:04 05:06:02
20100415_045645_BRP.edf Flow 25 Hz 0.04 sec 04.56.53 04:56:53 05:06:53
20100415_045645_EVE.edf Event/Annotation Event Driven Event Driven 04.56.59 n/a n/a

Notes:

- two of the files (SAD,PLD) have names with embedded timestamps which imply a 1 sec lag in time of creation
- it looks like ResScan made allowance for the 1 sec lag in file creation by adjusting the start time of the graph for Pressure/Leak back by 1 sec
- the ResScan graph for Flow Data lasts exactly 10 minutes
- the pressure/leak data graph runs 2 secs short of 9 minutes
- sample interval for pressure/leak data is once every 2 secs
- there is skew of 12 secs in the timestamps in the file headers of the BRP (flow) and PLD (pressure/leak) files; the PLD file lags
- from earlier testing, the BRP and PLD files are only written to SD card once a minute

I have no time left this evening to compare other files or draw conclusions from this in detail, but this has set me thinking. I hope I can make sense of it tomorrow. At a minimum maybe it will help ME sleep better tonight!

Just picked up replacement S9 and Humidifier on Saturday...
Now I have NO Skew... starting over.
I will follow same process as before replacement BUT...
I am using original ResMed Card as formatted from factory.

NOTE: It is formatted FAT 16... not FAT 32 from factory.

Nord

[DreamOn]

Thanks to Nord and everyone else who are continuing this investigation. It'll be interesting to see what you discover with this new machine, starting over from scratch, Nord!

[DreamDiver]

NOTE: It is formatted FAT 16... not FAT 32 from factory.

Huh. Mine was formatted FAT32 from the factory.

[Nord]

NOTE: It is formatted FAT 16... not FAT 32 from factory.

Huh. Mine was formatted FAT32 from the factory.

I plan to stick with this card and not change anything else... until skew.
I can't see why FAT 16 would be any different and alterego61 has been using a FAT 32 card since acquiring the S9 and he has no Skews...

I was exploring that earlier on... but...

Nord

[kennethryan]

NOTE: It is formatted FAT 16... not FAT 32 from factory.

Huh. Mine was formatted FAT32 from the factory.

Hmmm... So was mine.

I wonder if fat16 vs. fat32 makes a difference? Theoretically they shouldn't, but past experience debugging an embedded system with a CF card showed sometimes it matters (in that case fat32 made it break).

Perhaps someone who is experiencing the skew problem should look at the format, and try reformatting the other way to see if it matters?

[Nord]

NOTE: It is formatted FAT 16... not FAT 32 from factory.

Huh. Mine was formatted FAT32 from the factory.

Hmmm... So was mine.

I wonder if fat16 vs. fat32 makes a difference? Theoretically they shouldn't, but past experience debugging an embedded system with a CF card showed sometimes it matters (in that case fat32 made it break).

Perhaps someone who is experiencing the skew problem should look at the format, and try reformatting the other way to see if it matters?

Trouble is... we've had FAT 32 cards that have been both skewed and not skewed... but I still have some doubts and I haven't gotten the idea out of my mind yet. Now that I have a FAT 16 card direct from factory... I am following where it takes me.

Nord

[dave21]

The only difference between FAT16 vs FAT32 is that FAT32 supports smaller cluster sizes, so if you have hundreds of 512 byte files, on FAT32 each one could take up 512 bytes, instead of say 4kb on FAT16. It just means you can fit many smaller files onto the same card without running out of space quicker.

The other factor of FAT32 is to fully support LFN (Long File Names). LFN is file names > 8.3 (8 characters for prefix and 3 characters for suffix).

Thanks
Dave

[Nord]

The only difference between FAT16 vs FAT32 is that FAT32 supports smaller cluster sizes, so if you have hundreds of 512 byte files, on FAT32 each one could take up 512 bytes, instead of say 4kb on FAT16. It just means you can fit many smaller files onto the same card without running out of space quicker.

The other factor of FAT32 is to fully support LFN (Long File Names). LFN is file names > 8.3 (8 characters for prefix and 3 characters for suffix).

Thanks
Dave

I agree Dave... that it should essentially operate in a similar way with either File Allocation Table 16 or 32... but I am noting that it is different and FAT 16 operates differently from FAT 32 in a number of ways that I don't really want to discuss at this point.

I just thought it odd that when I looked, it came from the factory that way and after noticing... I will leave it as is and see if there are differences for the S9.

Two days and NO SKEW so far...

Nord

[DreamDiver]

Two days and NO SKEW so far...

Nord - now that you have a new machine, I don't know if the difference between FAT32 and FAT16 will matter. If the problem is not in the SD card - and I'm beginning to think it's not - either valid format should show skew if it's going to happen at all. If after 20 sessions you aren't seeing skew, you could try FAT32. If you see skew then, perhaps it's the card. But I suspect you won't see skew in FAT32 if you didn't see skew in FAT16.

Your machine may be one of the machines that will not show skew - in which case, you're in a unique position to look at the serial/lot data comparison again.

[Nord]

Two days and NO SKEW so far...

Nord - now that you have a new machine, I don't know if the difference between FAT32 and FAT16 will matter. If the problem is not in the SD card - and I'm beginning to think it's not - either valid format should show skew if it's going to happen at all. If after 20 sessions you aren't seeing skew, you could try FAT32. If you see skew then, perhaps it's the card. But I suspect you won't see skew in FAT32 if you didn't see skew in FAT16.

Your machine may be one of the machines that will not show skew - in which case, you're in a unique position to look at the serial/lot data comparison again.

I will be doing that DreamDiver... I'm not getting a very good response yet for the Serial Numbers... perhaps it'll just take some more time.

Thanks
Nord

[kennethryan]

The only difference between FAT16 vs FAT32 is that FAT32 supports smaller cluster sizes, so if you have hundreds of 512 byte files, on FAT32 each one could take up 512 bytes, instead of say 4kb on FAT16. It just means you can fit many smaller files onto the same card without running out of space quicker.

The other factor of FAT32 is to fully support LFN (Long File Names). LFN is file names > 8.3 (8 characters for prefix and 3 characters for suffix).

Well, almost. The primary reason to go FAT32 is larger partition sizes. Cluster sizes help, but don't get all the way there.
Even today, Windows will format smaller devices as FAT16; where the size threshold is depends (IIRC) on what Windows version you're using (or if you're using an alternative platform). FAT32 also removes the limitation on root directory entry count.

BTW, long filenames work on both FAT16 and FAT32. It's an enhancement to the directory entry format, it doesn't affect the FATs per se.

But the cluster size does bring up an interesting angle I didn't think of. Windows treats flash cards the same as a disk drive; with sectors a certain size. SD cards report a sector size of 512 bytes (Windows doesn't allow fixed disk drives to have any other sector size). However flash memory physically has a different block size - 2KB or 4KB depending on whose chips are in use. FAT treats the cluster as the atomic unit for file allocation (but still reads and writes by sector). There is a mismatch between how Windows treats the media and its physical capability. To make matters even more fun, the peculiarities of how flash memory is accessed for writes means the flash controller (a chip inside the SD card) has to do all sorts of memory management in real time, as data is getting written. At the worst case, Windows thinks it's writing a single contiguous 4KB cluster but the flash controller chip has to read, erase, reallocate, and rewrite 8 distinct memory blocks! This flash memory management is really what separates a good-quality high-speed card and the cheap crap. BTW, this problem gets magnified if you keep rewriting the same sectors over and over, as with directory entries and files getting written a few bytes at a time - pretty much our usage case. In those cases you don't have to fill up the card to start fragmenting badly, simply rewriting the same sector over and over will do it nicely.

Maybe after a certain amount of use the card memory blocks are getting too fragmented and getting too slow. Note that a normal formatting of the card won't help this - the card has no idea you're formatting it, it simply thinks you're writing different data (there exists manufacturer-specific software to do a low-level format; it's usually hard to get though).

Anyway, I obviously don't know for sure if that's the problem, but it is something to keep in mind...however if this was the case then I would expect those using higher-speed cards (class 6 & up) to be much less likely to see the problem. I also can't get over how low the data rate actually is (what, 1 or 2 floating point values at 25Hz? That's still less than 1KB/s).

OK, I'm talking myself in circles. Time to hose up and get to bed...

ken

[Nord]

4 days with replacement machine... no progressive skew issues.

Nord