Jump to content
HWBOT Community Forums


  • Posts

  • Joined

  • Last visited


  • Location

IanCutress's Achievements


Newbie (1/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Posting Machine Rare
  • Week One Done Rare

Recent Badges



  1. Please change my nickname to IanCutress, thanks
  2. 8x128GB LRDIMMs. Yeah, LRDIMMs timing is bad because of additional buffer chips. But it's a server board, I didn't expect anything more.
  3. No client version given, required version: 0.9.6 ?! Using, submit through the interface.
  4. High DPI: It's one of those things everyone is trying to get right. Perhaps offer two versions of the interface, one that fits nicely into a 4K screen Screenshot: Awesome, thanks Time left/time taken: Also, thanks! CLI: I ask for this in the sense that say I'm testing a bunch of CPUs at stock for a review, and I want to automate the process but still have the results applicable for comparison. So you can disable HWBot submissions with CLI mode, but just so I could get a score out without having to babysit my benchmarking routine. 8K: Do it. Do it. Do it. If you can find an appropriate video to add to the download (1GB?). You'll be surprised and how the x265 algorithm deals with small frames and big frames, where L3 cache / eDRAM matters and whether it can exploit IPC. That's when the step ups to larger L3/core might be more significant. MultiCoreWare: Like I said, I only discussed it as part of an IDF meeting and they hadn't given it much thought at that point so you wouldn't have seen any basic benchmark online from them yet. But we did discuss and they were keen - they'd work with anyone who is/was willing to develop one and spread it out.
  5. My input: Doesn't display properly on HiDPI displays - allow for 150% / 200% scaling. The submit 'take a screenshot' takes a long time when running high resolution displays. If you're going to implement a result submission that relies on a checksum, I'd suggested limiting the screenshot to an ALT+PRTSCN application that just captures the benchmark window. Show the time taken to process the benchmark at the end Show the estimated time to complete during the benchmark Allow a command line interface to run the benchmark which screenshots the result, saves the HWBOT file, and quits out automatically. That way someone could script up 50 runs and just choose to submit the best. Automatically generate a result text file with a verbose output, or in the log include the benchmark result. Include 8K. For LOLz. Out of interest, have you spoken at all to MultiCoreWare in preparing this benchmark? They develop the x265 algorithm which is meant to be the toughest and most efficient in the business. I had a good long chat with their VP of product management about our own x265 encoding tests at AnandTech, relating to overclocked stability while transcoding, last week at IDF. We even discussed the potential of an open benchmark, like x264 HD 5.0 and the like. Looks like you're already ahead here, albeit with Java in tow. But it might be interesting if you did a cross collaboration on this. I can make intros where necessary, hit me up.
  6. Submitted to wrong benchmark. This is a 3DPM-MT score, you subbed to 3DPM-ST
  7. Ticket ID: 1920 Priority: Medium Bascially I need all of these added:\r\n\r\nhttps://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#Xeon_E5-2xxx_v3_.28dual-processor.29\r\n\r\nAll the way up to the 14/16/18 cores
  8. Wrong benchmark. You ran the multi-threaded version, which is 3DPM-MT. You need to resubmit in the right benchmark.
  • Create New...