You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test-perf-hooks failing on v18.x SmartOS CI #57000
Please add me ( @danmcd ) to the platform-smartos team in the short term. ANd in the longer term we need to make this "ILLUMOS" because it affects all illumos distros, not just SmartOS.
I know we provide resources, but with the recent departure of @bahamat I want to make sure our end is informed and active.
BTW, due to strange-to-me OAUTH requirements of the ci.nodejs.org, I cannot yet see the CI links posted above. Asked for permissions too from orgs I belong to, but am not an admin in. That's odd, but honestly the orgs in question are illumos-related, so it's good you know that in the long run this is about illumos, not just SmartOS.
BTW, due to strange-to-me OAUTH requirements of the ci.nodejs.org, I cannot yet see the CI links posted above. Asked for permissions too from orgs I belong to, but am not an admin in. That's odd, but honestly the orgs in question are illumos-related, so it's good you know that in the long run this is about illumos, not just SmartOS.
Yeah, one org I belong to declined you because it wanted private repos. COuld be a rate-limit thing so I'll try again tomorrow.
I STILL can't access the CI @aduh95 because one of my orgs won't grant permission (private repos). Would appreciate assistance in being able to see the three failures so I can help.
You can find the output in #57000 (comment); other than that, you should be able to access the CI as long as you have a GitHub account, you shouldn't need to get permissions (at least, not from our side).
I would recommend getting access to the CI, and watch failures in daily builds, that's the best place to spot flaky tests.
as long as you have a GitHub account, you shouldn't need to get permissions (at least, not from our side).
Yeah, I thought that was all I needed too, but OAuth is whining at me a lot. First about needing org access, then rate-limit blocking me after too many tries. :(
So the margin-of-error on this test is +/- 50 (units unclear), and for some reason we seem to be exceeding that (53, 62, 82 (units unclear)).
I do not know the machines/VMs we provide for this, but if they are VMs on loaded compute nodes, such jitter could be introduced by overloading. I see one other set of tests was marked as possible-flaky:
and the short-term fix would be to add this for test-perf-hooks as well. I know the illumos (and Solaris) gethrtime() should provided the nsec-granularity time a higher-level entity would need. This expression:
Makes me wonder which terms get their respective timestamp data from?
Date.now()
performance.timeOrigin()
process.uptime()
I'm pretty sure I know where to get sources for all of those (and would Date.now() might be subject to NTP-driven drift?), but I wonder if on a loaded-compute-node VM would any these get enough jitter to exceed your margin of error?
Activity
aduh95 commentedon Feb 10, 2025
/cc @nodejs/platform-smartos
[-]SmartOS `test-perf-hooks` failing on v18.x[/-][+]`test-perf-hooks` failing on v18.x SmartOS CI[/+]danmcd commentedon Feb 26, 2025
Please add me ( @danmcd ) to the platform-smartos team in the short term. ANd in the longer term we need to make this "ILLUMOS" because it affects all illumos distros, not just SmartOS.
I know we provide resources, but with the recent departure of @bahamat I want to make sure our end is informed and active.
jclulow commentedon Feb 26, 2025
NB: I've created nodejs/admin#954 about adding you, @danmcd.
danmcd commentedon Feb 26, 2025
BTW, due to strange-to-me OAUTH requirements of the ci.nodejs.org, I cannot yet see the CI links posted above. Asked for permissions too from orgs I belong to, but am not an admin in. That's odd, but honestly the orgs in question are illumos-related, so it's good you know that in the long run this is about illumos, not just SmartOS.
danmcd commentedon Feb 26, 2025
Yeah, one org I belong to declined you because it wanted private repos. COuld be a rate-limit thing so I'll try again tomorrow.
danmcd commentedon Feb 27, 2025
I STILL can't access the CI @aduh95 because one of my orgs won't grant permission (private repos). Would appreciate assistance in being able to see the three failures so I can help.
aduh95 commentedon Feb 27, 2025
You can find the output in #57000 (comment); other than that, you should be able to access the CI as long as you have a GitHub account, you shouldn't need to get permissions (at least, not from our side).
I would recommend getting access to the CI, and watch failures in daily builds, that's the best place to spot flaky tests.
danmcd commentedon Feb 27, 2025
Yeah, I thought that was all I needed too, but OAuth is whining at me a lot. First about needing org access, then rate-limit blocking me after too many tries. :(
danmcd commentedon Feb 27, 2025
WHOA NEVER MIND! Somehow it cleared up!
danmcd commentedon Feb 27, 2025
So the margin-of-error on this test is +/- 50 (units unclear), and for some reason we seem to be exceeding that (53, 62, 82 (units unclear)).
I do not know the machines/VMs we provide for this, but if they are VMs on loaded compute nodes, such jitter could be introduced by overloading. I see one other set of tests was marked as possible-flaky:
#56583
and the short-term fix would be to add this for
test-perf-hooksas well. I know the illumos (and Solaris) gethrtime() should provided the nsec-granularity time a higher-level entity would need. This expression:Makes me wonder which terms get their respective timestamp data from?
I'm pretty sure I know where to get sources for all of those (and would Date.now() might be subject to NTP-driven drift?), but I wonder if on a loaded-compute-node VM would any these get enough jitter to exceed your margin of error?
targos commentedon May 1, 2025
v18.x is now EoL.