TRENDING TOPICS INTEL AMD CPUS STORAGE GPUS MOBILE SSDS SMARTPHONES LAPTOPS
by Ian Cutress & Ryan Smith on April 25, 2018 11:15 AM EST + Add A
Comment
Posted in CPUs AMD Intel Spectre Windows 10 Ryzen Core Meltdown
GIGABYTE Launches
Two 4U NVIDIA Tesla
GPU Servers: High
Density for Deep
Learning
HP Unveils EliteBook 700 G5,
ProBook 645 G4 Laptops with
Ryzen PRO & Thunderbolt 3
TWEETS
IanCutress: @megatomic70 Is it working yet,
or are there still issues?
Ryan Smith - Wednesday, April 25, 2018 - link RyanSmithAT: @IanCutress The trick is to go
Correct. We knew at the start of the Ryzen 2 review what benchmarks and what products we wanted to in the off season. Everyone wants to go in
include; this timer issue hasn't changed that. the summer for vacation or in
November/De… https://t.co/gZYcLMWTxr
REPLY
ganeshts: @DTheSleepless Specs in DM,
freaqiedude - Wednesday, April 25, 2018 - link please :)
So would it be fair to say that Intel’s HPET implementation is potentially buggy? It seems to cause a
ganeshts: @david_schor EETimes coverage
disproportionate performance hit.
indicated they are going to use RISC-V for
REPLY their upcoming 64-bit CPUs.
chrcoluk - Wednesday, April 25, 2018 - link ganeshts: @FPiednoel I hope it will happen
within my life time :) A lot of love for self-
no its just that TSC + lapic is the way to go, There is a reason thats the default in windows and other
driving cars is from folks who are…
modern OS's.
https://t.co/a9LjwMSp46
REPLY
What's new to the general tech site reading public is that there are apparently significant differences
in the size of the impact between different CPU families.
REPLY
Nvidia has been shown to cheat in the past on benchmarks by turning off features in certain
games that are used for benchmarking to boost the score. Is Intel doing something similar?
REPLY
Rob_T - Wednesday, April 25, 2018 - link
I came across a similar issue on VMware, where a virtual machine's clock would drift out of
time synchronisation. The cause of this was that VMWare uses a software based clock and
when a host was under heavy CPU load the VM's clock wouldn't get enough CPU resource to
keep it updated accurately. This resulted in time running 'slowly' on the virtual machine.
Under normal circumstances this kind of time driftissue would be handled by the Network Time
Protocol daemon slewing the time back to accuracy; the problem is the maximum slew rate
possible is limited to 500 parts-per-million (PPM). Under peak loads we were observing the
VM's clock running slow by anywhere up to a third. This far outweighed the ability of the NTP
slew mechanism to bring the time back to accuracy.
If this issue has the same root cause, the software based timers would start to run slowly when
the system is under heavy load. Therefore more work could be completed in a 'second' due to
it's increased duration. It would be interesting to know if the highest discrepancy were also the
ones with the largest CPU loads? Looking at the gaming graphs on page 4 the biggest
differences are at 1080p which suggests this might be the case.
REPLY
1 2 3 4 5 6 24 ▶
The Most Trusted in Tech Since 1997 About Advertising Privacy Policy