failing_disk

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:08:55 +0000

2014-05-02 - failing disk

some time ago my sister started to complain about her laptop working slow and freezing often, at random moments, for a few seconds. a bit of testing shown no (known) viruses, next to none CPU load and next to none extra I/O (well – it was windows, by let's say it was close enough to zero). after some time i decided to run a disk scan, using hdd scan. plot of reading speed vs. position on disk looked like this:

there are clearly locations on the disk, that do not work well – transfer drops there significantly. around 3/4 of the way i dropped to a nearly zero. clearly disk was dying.

the funny thing is how it is happening. “regular” disks have extra logic that tries to correct errors along the way: move failing sectors, correct corrupted data, mark bad blocks… from the user point of view all of this results in a performance drop, up to a “random freezes” point. this might be nice/acceptable for regular user, as one just want's be able to copy her data out of a dying surface.

this is however a pain in the neck when you have a RAID (non-0 RAID, to be precise) on your computer. having the same data on more than one disk means fail-fast is the best approach. if disk cannot read something, it should just mark block as dead, report an error and let RAID controller read required data from other (usually still operational) disk. this is the tactics so called “RAID edition” disks have. the problem is their price, which is usually ~2-4x more expensive than “regular” ones. funny part is having an extra (error-correcting) logic, means lower price. ;)

any way, after buying a new drive plot came back to normal:

the new disk looks (more-less) healthy. though both disks had the same capacity, new one is significantly faster. from the plot one can also see this is clearly a rotary-plate drive, as reading speed decreases while moving towards end of disk pace (i.e. center of the disk). this happens due to non-uniform sectors density in each cylinder, that increases both capacity and speed, while moving away from the center of the disk (physical CHS is a thing of the past for decades now).

spi_atmega64_a

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:08:55 +0000

2014-05-02 - SPI@ATmega64(A)

while doing an AVR-based project with friends, we decided to switch from ATmega169 to ATmega64A, which has 4x more program memory and is easier accessible on retail market. after soldering µC on our prototype board we were unable to flash it. 4 ppl checked the schema twice to see if SPI is connected to proper MISO, MOSI, SCK and reset pins. cable has been checked… and then one of friends found an interesting post on the net, saying that SPI from programming ATmega64(A) should be connected to PE0 and PE1, instead of PB2 and PB3, as pinout suggest:

a bug this big in a datasheet? at first i though this might be a matter of a bootloader – PE0 and PE1 cab be used by USART0, after all. after having a quick look at an ATmega64A datasheet, section 28.8 resolved a mystery:

quoting:

Even though the SPI Programming interface re-uses the SPI I/O module, there is one important difference: The
MOSI/MISO pins that are mapped to PB2 and PB3 in the SPI I/O module are not used in the Programming interface.
Instead, PE0 and PE1 are used for data in SPI Programming mode as shown in Table 28-13.

so this is a feature, not a bug, after all… how obvious and how convenient! looking though forums shows that many ppl fall into this trap around the world. despite this is tricky, this is not the way it is done in other popular AVRs, like ATmega8, ATtiny13 and others, i had worked with before.

The nice thing about standards is that you have so many to choose from.
– Andrew S. Tanenbaum

BaSzErr - blog:2014:05:02

failing_disk

2014-05-02 - failing disk

spi_atmega64_a

2014-05-02 - SPI@ATmega64(A)