Deadline Really Bad



  • Hi, i'm minning burst for a lot of time and i have this message
    0_1505687272673_97b9d9ae-b44c-4f3e-a4b0-b4e8684b813f-imagen.png

    Can help me Please



  • 0_1505687621090_a84dd6f9-7ca5-4b1c-9851-94ec3d277d11-imagen.png

    And its correctwhen say no deadline ?



  • @warj4r if this continues, I would suggest replotting. Otherwise, it could be a one off thing.



  • I go try to replot



  • @warj4r how much space do you mine ?

    It is not unusual to have a bad bit read from a disk every 12 TB, as this is the statistically given value for consumer SATA drives (10^-14). Bits on the platter are physically small (a few hundred atoms in diameter), so there's lots of checksumming involved and the actual read is a "guess the data"-process. The error correction algos have a statistical chance to fail, and this is given in the datasheets as unrecoverable read error (URE). That is, the error correction fails sometimes and you have a chance of reading a block without the drive noticing corruption.

    What does that mean in a real-world scenario like burst-mining ?

    If you mine 10 TiB of plots, on every block you read 2.5 GiB (10 TiB/4096). So, every 4915 blocks (12 TiB/2.5 GiB == 4915) you read and process a bad bit, wrecking your deadline. 4915 Blocks is every 13.6 days. This is a probability, so you could go unharmed for 100 days or even have a streak of bad luck with 10 bad reads on a day.

    If you see this error more often, it might be a good idea to replot, as there is more bad(ly read or written) data than statistics allow for.

    And you have a lot more error sources in a typical setup; the USB3 bus, the USB3-controller&Hubs, PCIexpess bus, a non-ECC secured main memory, non-ECC secured memory buses).

    There are filesystems out there that compute a checksum for every block transaction at the OS layer, thus preventing these read errors to go undeteced (and wreck your application), namely btrfs and zfs (on Linux, Solaris et.al., OSX and FreeBSD).

    Usually, these errors go undetected in a home environment (as there is not enough data on disk and in transport). But Bitrot (as its casually called) is a major problem in larger installations and you start to recognize it if you store or move a lot of data. And that could mean a mere 100 TB, depending on access patterns. I've been burned by that in a professional context. My client switched from SATA to SAS (URE: 10^-16) and implemented zfs, problems gone. Research "bit rot".



  • You also need to accurately sync your computer to windows time.Try a free time sync program.
    Try Dimension4



  • @vaxman i have 5190 GB in 3 hard drives.
    1 hdd --> 4 TB Western Digital Red
    1 hdd --> 750 GB seagate
    1 hdd --> 1 tb seagate



  • @warj4r said in Deadline Really Bad:

    Hi, i'm minning burst for a lot of time and i have this message
    0_1505687272673_97b9d9ae-b44c-4f3e-a4b0-b4e8684b813f-imagen.png

    Can help me Please

    another reason you might see this is if you are scanning plots while a new block has arrived and you're submitting a deadline for the old block, which will get rejected with an error similar to this because that deadline you found now doesn't calculate well for the current block...

    when we look at block 404938 and 404939 we see there was a short period in between them, now since you're reading your drives in 5 seconds I can't imagine that 30 some odd seconds should have resulted in a new block before you were aware of it, but crazier things have happened when folks or pools are out of sync...

    however as others pointed out, if this is a message you rarely ever see, its not likely a huge issue, but if you see this often enough to notice it, then yeah you might want to replot the particular drive you are getting these messages from, if you're able to narrow it down to a specific drive... this is why it says "wrong block?" "files corrupt?" because its trying to give you two possible reasons why this happens...

    https://explore.burst.cryptoguru.org/block/15544024118655170689

    https://explore.burst.cryptoguru.org/block/4326407893925790653

    you can see the close timestamps of those two blocks...



  • sorry but i dont understand i'm spanish



  • @warj4r said in Deadline Really Bad:

    sorry but i dont understand i'm spanish

    hey maybe @Energy can help ya out



  • @warj4r
    short answer:

    1. if this does not happen more often than once or twice a week, ignore it.

    2. make sure your system time is set correctly.
      If using Windows, read up on "w32tm" and how to synchronize to external ntp sources; e.g.
      http://adriank.org/windows-server-2008-r2-sp1-sync-time-external-time-source/

    w32tm /config /manualpeerlist:"time.windows.com,0x1" /syncfromflags:manual /reliable:yes /update
    w32tm /config /update
    net stop w32time && net start w32time
    


  • que pool estas usando?
    Has tenido ese error mas de una vez y si es así conque frecuencia?

    What pool are you using?
    Have you had that mistake more than once and if so, how often?



  • Estoy usando Burstcoin space , y la verdad que ese error no para de darmelo , he formateado los disco otra vez y lo he puesto ahora solo con 1 de 4tb wd red que funciona perfectamente.
    Cada vez que me sale Found DL me da ese error y no me está generando ningún burst en mi cartera :(

    Lo de sincronizar el tiempo no tengo ni p*** idea como se hace , con perdón de la expresión.
    Llevo varios dias intenandolo mirando varios tutoriales y foros y no me salgo.
    Cuando hago el plot del disco lo hago desde el mismo Burst Wallet que me da la opción y mino también desde ahí.


Log in to reply
 

Looks like your connection to Burst - Efficient HDD Mining was lost, please wait while we try to reconnect.