My Discord is Wolf9466#9466 - unique ID is 598179163160969216.
My Telegram is @Wolf9466.
My personal Discord server is here!
If you're looking for my writings, you can find them
here!
If you're looking for my NSFW galleries, you can find them
here!
Just call me Wolf. I have gone by Wolf, Wolf0, Wolf9466, and OhGodAPet, although
I consider Wolf9466 or just Wolf as my current. I'm... well, anywhere I can set
up computer shit, I guess - although I have traveled out of the country and such.
I began when I was 13 or so, starting with C++. I remember I didn't like it, got
a book on C, and found it less of a hassle to learn. I have always wanted to make
low-level stuff, so I wanted to write an OS. I'll just skim over the highlights of
that project: I started it around 13 years old, I began with BIOS boot. You get 512
bytes of code to find the REST of your code and jump to it. Nightmare. Still, I
managed it, and eventually got to long mode (x64 mode) and booted my own kernel. I
did some drivers and a physical memory manager, but when I saw how x86-64 handles
virtual memory (paging), and I just gave up.
My next large project was an app with a Win32 GUI - its purpose was to manage
updating and reproducing collections of art off a couple of sites. The main
site I wanted to target did not have an API (it still doesn't) - and at that
stage in life, I was even more against pulling in dependencies than I am now.
This means, I crafted my own HTTP requests in C, and parsed the HTML in C to
extract links to full-size images, and then to fetch the images themselves.
C has absolutely horrid string handling. In the end, I had two dependencies:
openssl (FurAffinity requires you to log in to view NSFW art except through
a direct link) and optionally zlib, for compression of the data coming from
the server. It could search by artist, and filter by rating (safe, mature,
adult), source of the image (the artist's gallery, scraps, or favorites) and
more. I put a hell of a lot of work into it, and later expanded it to support
e621 (which thankfully does have an API.)
Following that, I began doing miner development in 2014. It began as me finding
a coin that was new at the time, XMR. The public CPU miner was horribly slow. It
was badly done, and since I was good at low-level and optimizations, I just *had*
to fix it, like OCD. You can still see some of that from 2014 here:
https://github.com/lucasjones/cpuminer-multi/commit/6564b2740761536078716b1ec927557029ae1633
I wasn't even aware at the time that what I was able to do was valuable... well,
not until someone paid me to stop.
So... there's this new FPGA miner which is being produced, the Osprey E300, and I have good reason to believe that quite a sizable amount will be made and sold. The current firmware has very little to offer in terms of easy management capabilities, or detailed statistics reporting. It does have a WebUI, but it is rather barren. The few tunable options which are available (such as limited control of clock speeds and voltages) are only offered via miner programs - and those options are *FAR* from complete, compared to what is possible on this machine.
For background, almost all of my projects (even those I've made money off of, interestingly enough), I have done mainly for dumb reasons or pure fun. This means that even if I do decide to try this and I succeed, I haven't the foggiest idea what I'd do with it. My writeup on it, which I'll try to update as I go along, is here!
Xilinx are underclocking the HBM2 (forcibly - the user is unable to change it as
their encrypted HBM IP will not generate settings for its internal PLL to run the
memory above 900Mhz. The part is Samsung Aquabolt HBM2, and it's actually specified
by Samsung for 1000Mhz - 1200Mhz (depending on binning). Many researchers,
companies, and others benefit from the performance of these parts. They also
hide the details of the configuration ports for their hard memory controllers and PHYs...
So I'm working on reverse engineering over a hundred registers, and changing the clock
speed, but it's not that simple. You see... one does not simply change PLL settings.
You must to put the MCs in reset, put the PHYs in reset, then change with whatever
you want, but then you gotta bring up the PHYs, make sure they don't spew garbage
during init, then release MCs from reset, then calibrate them...
In short, you have to bring the entire memory system back up. By yourself.
I recieved an official reply from Xilinx, and in my opinion, their answer was quite good - they do admit I was right about the HBM parts - they are specified for 1000Mhz. However, due to the reliability guidelines stated in the datasheet (which seem to confirm the idea that it's the FPGA fabric is the limiting factor - speedgrade -1 devices have a max of 800Mhz, while the faster -2 and -3 speedgrades have a max of 900Mhz), there's a real chance that it won't be able to maintain those data rates when process variations are considered, and having to meet power rail requirements, as well as reference clock quality guidelines. Further, there is no way for the user to make those changes, because it would force them to take returns/RMAs on parts which meet the expectations laid out by the datasheet, but would fail at higher HBM data rates. It's also a support issue - allowing users to exceed the max speed of the supported use case could cause failures for end customers, and that would put Xilinx in a bad light. Their official answer can be found here.