Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

About Poet129

  • Title
  • Birthday Nov 15, 2004

Contact Methods

Profile Information

  • Location
    On the other end of your ethernet cable.
  • Gender
  • Occupation


  • CPU
    Dual Intel Xeon X5667 @ 4.02674 GHz @ 1.35V
  • Motherboard
    EVGA Classified SR-2
  • RAM
    32GB DDR3 ECC @ 1750.4
  • GPU
    NVIDIA GeForce GTX 1050 Ti + NVIDIA Tesla K40m
  • Storage
    512 GB SSD, 2 1 TB, and 1 512 GB Hard drives in Raid 0
  • PSU
  • Display(s)
    52 inch TV 1080P @ 77Hz + 22 inch AOC LCD Display 1080P @ 66Hz
  • Cooling
    8 Fans
  • Keyboard
  • Mouse
  • Operating System
    Windows 11 Enterprise
  • Laptop
    Lenovo E530 8 GB Ram

Recent Profile Visitors

1,804 profile views
  1. Would have done 100 MiB file, but wanted it to be natively uploadable. I replaced RLE with a built in (zlib) so the program should now work with Windows. (Updated on github) The decompression speed on my i5-2450m was 5 seconds. The compression time was not measured as the file was created for testing decompression along with file sizes, however my estimate would be about 69 heat deaths of the universe... I'm working on getting this to be faster. Test.7z Test.CRS
  2. I'm looking at the issues one by one this is first. For the first bolded section, I've actually tried this here, however found that it was far to slow for anything greater than 2-3 bytes. For the second bolded section, I've already questioned this myself and noted as one of the current issues... This is currently been limited to 56 bits instead of 64 even. Is there any PRNG that has an unlimited number of seeds that is known about? No. During testing with CUDARAND which uses the same PRNG I've tested across multiple computers and oses Ubuntu, Mint, and Windows. The out
  3. As stated I'm making a new compression method that I'd like help with. I've made everything it needs to work with some contributors not active but with other's code. The way this compression method works is by sorting the bytes for maximum compression with RLE, while returning the normal order using a shuffler that takes seeds. Compression works essentially by brute forcing finding what seed will consistently randomly shuffle the bytes into the correct order. I've included a test file along with other compression methods on the same file (the three built in to ubuntu). Naturally th
  4. Where can I get one of those programmers? Luck would have it that my pc crashed while I was flashing the VBIOS. I think I found one... https://www.overclock.net/threads/brand-new-method-how-to-unbrick-flash-almost-any-card-amd-or-nvidia.1612108/ https://www.amazon.com/gp/product/B013Q5P3ES/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 https://www.amazon.com/gp/product/B015W4PKR6/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
  5. Not that we really didn't already know this, but this shows that the limitation has been set in the VBIOS. So NVIDIA choose to do this and choose once again to not release any kind of fix for it... I understand why, but I'd obviously really like them to just fix it. I know it won't happen though. After looking at the views on this page I've started to wonder if anyone from NVIDIA saw this...
  6. So most likely not a set limit just the hardware wearing out... I've probably flashed this card at least a hundred times or so.
  7. How many flashes is the maximum? I actually don't have a clue...
  8. I believe I have figured out what is going on finally... so with the K40c BIOS at start, the boot sector of the VBIOS is loaded into VRAM at start. Then flashing the K40m VBIOS correctly Identifies itself. So following this logic all that needs done is to get the sections telling the VBIOS what it is from the OG K40m VBIOS and pairing that with the boot code of the K40c VBIOS. I've yet to get a working configuration due to a corrupt boot sector supposedly. I've still managed to not brick the card though... yet.
  9. It has been a while since I posted here... just an update, no progress on maintaining gpu availability across restarts, however I've now tested with multiple nvidia drivers and Windows 11, and they all work fine.
  10. I get about the same value between both the miners I've tested one reporting 20-25MH/s, the other reporting spikes of 2200MH/s and an average of 220MH/s. I'm pretty sure it is reporting wrong. XMRIG is the one reporting wrong on OPENCL if anyone is curious.
  11. I'm at stock clocks, I've now tried other miners, none report anything close to this I'm assuming it was just reporting wrong, however I thought I may not be correct.
  12. Mining the KAWPOW algorithm with my Vega 56 on XMRIG with default config, gave me upwards of ~2200 MHashes a second. I looked it up to only be 20 MHashes a second. However this speed seems very unstable and only gets roughly ~200 MHashes a second on the 15 minute average. Any way I can fix this?
  13. Type it in the windows search bar it should show up.