Consider they are morons. They did delegate the problem to the person they saw was the expert and implemented the expert’s idea. They didn’t have much patience, but you can’t dispute the delegation.
I suspect that won't help. The reason the Moon needs a time zone is because of gravitational time dilation, time literally runs slower down here on Earth's surface relative to the Moon's surface. A computer on the Moon gains an extra 58.7 microseconds each Earth day, so if you're programming something that'll be running on Lunar time you'll need to account for that.
The point of the lunar time zone is not to have a specific UTC offset like other timezones. The moon would have its own set of atomic clocks, and time could be coordinated with earth based on ratio instead of offset.
They're not going to be maintaining literal atomic clocks on the Moon for this. They'll apply a mathematical adjustment to UTC based on what the physics calculations say is happening. The details of that adjustment are what NASA has yet to develop. I expect it'll probably involve subtracting a "leap second" from lunar time at intervals, leap seconds are already used for keeping UTC in sync with the solar time so it's an established process.
They probably actually will end up with atomic clocks on the moon, or at least in close lunar orbit. If the plan is to have something like gps on the moon, that’s a first step.
UTC doesn’t become wrong, you can either just accept a different pace of the clock, i.e. earth ppl will be ever so late to a meeting or it’s just a different kind of timezone conversion. Better would be to have a single time based on the reference frame of the center of the galaxy and everyone keep there time relative to that.
just use a time based on light?, like meter is based on the speed fo light in the vaccum, or use atomic based times?, like how long take for the hydrogen atom todo something bla bla bla
That’s actually what’s different on the moon. Relativity and all that means that time itself actually flows differently on the moon than it does on earth.
The actual problem they’re working to solve is around timekeeping and GPS applications in different reference frames, but it’s hard to make a short headline about.
When I first saw the news I was thinking “there’s no way atoms vibrate differently on the moon” but you’re right it’s about perspective and I’ve realized there’s no way I’m smart enough to handle timezones on an interplanetary scale. I can only hope that the difference between earth seconds and moon seconds can be expressed as a consistent ratio.
I will gladly use some programming library invented in the basement of a university powered by coffee, and rage.
It’s not too bad. Relativity says that no frame of reference is special.
On earth, a second looks like a second, but a second on the moon looks too quick.
On the moon, the second looks like a second, but a second on earth looks too slow.
Both are actually correct. The simplest solution is to declare 1 to be the base reference. In this case, the earth second. Any lunar colonies will just have to accept that their second is slightly longer than they think it should be.
If it helps, the difference is tiny. A second is 6.5x10^-10 seconds longer. This works out to 56 microseconds per 24 hours. It won’t affect much for a long time. About the only thing affected would be a lunar GPS.
Unfortunately, it’s not a useful one. While we know approximately where it is, we don’t know how deep the gravity well is. That gravity well slows the passage of time, just like the earth does. Without an exact mass, and mass density, we can’t calculate the correction factor.
It’s well understood math, but it’s “only” relativistic orbital mechanics.
It boils down to a pretty consistent number, but how you get there is related to the weight of the moon, how far it is from earth, and how fast it’s going.
Since the moon is going different speeds at different places in it’s orbit, the number actually changes slightly over the month.
They’re just using the average though, since it makes life far easier. We use the average for earth too, since clocks move differently at different altitudes or distances from the equator.
The second […] is defined by taking the fixed numerical value of the caesium frequency, ΔνCs, the unperturbed ground-state hyperfine transition frequency of the caesium 133 atom, to be 9192631770 when expressed in the unit Hz, which is equal to s−1.
Do not matter for relativity though, always same change.
So are you saying that a caesium-133 atom observed on both the Earth and the Moon to oscillate 9,192,631,770 times will not represent the same absolute span of time?
So, one observer will see those oscillations happen faster than the other?
Does this have to do with the specific gravity fields of both observers, in that those fields affect how the atom oscillates?
Or is there something else I’m missing?
If special relativity is the answer, all good. I’m an electrical engineer trained in classic physics, so I’ll rest knowing that I’d probably need to study that to understand the time differences.
So, one observer will see those oscillations happen faster than the other?
Not quite. In each observer’s frame of reference, time appears to pass the same; it’s only when you try to reconcile the between two objects that are not at rest with respect to each other does relativity show up.
Basically, when you bring someone back to Earth, the observers will find that their watches don’t match up even though both observers experience time passing the same way as normal (because the oberserver is by definition at rest with respect to their own frame of reference).
TL; DR: Relativity is a pain in the ass and makes no sense in everyday terms.
edit: disclaimer - I am not a physicist and have not taken physics classes in a decade plus, but I do teach science at a college. I’m going mostly on half-remembered lectures and some random one-off discussions I’ve had with my buddy in the physics department over the past few years.
It’s that relativity thing where each person will see the oscillations happening correctly, but when they look at what the other person did, the answer will seem wrong.
The difference is small enough that it really only matters if you’re NASA and building moon GPS. MPS?
No the second is still 9192631770 hyperfine transitions of Cs-133 on the moon and that’s the same length of time at least unless you want to severely annoy physicists by implying that the laws of nature aren’t constant through the universe. It’s just that from our perspective it looks like time is flowing differently there.
You are correct that if you are on thee moon and have a cs-133 atom with you is second will take that many transitions. And if you do the same thing on Earth, a second will take the same number of transitions.
But things get weird when you are on earth and observe a cs-133 atom that is on the moon. Because you are in different reference frames, you are traveling at different speeds and are in different gravity wells time is moving at different rates. This means that a cs atom locally will transition a different number of times in a second from your point of view on Earth vs one you are observing on the moon.
And it would all be reversed if you were on the Moon observing a clock back on the Earth.
They already have to account for this with GPS satellites. They all have atomic clocks on them but they don’t run at the same speed as clocks that are on the ground. The satellites are moving at a great speed and are further from the center of the earth than us, so the software that calculates the distance from your phone to the satellite have to use Einstein’s equations to account for the change in the rate of time.
So, in this case a moon timezone, and more generally a “space timekeeping framework” makes sense because time actually moves at a different speed on the moon, so epoch times wouldn’t actually stay in sync.
If the goal of “time” is to make it easier to reason about simultaneous things, then space makes that way more complicated.
It’s just tricky to condense that into a headline that conveys the point.
Yup. So building a system for “how we build time systems in different reference frames” and “define how we relate those to earth” isn’t irrational, just makes for headlines that are either difficult or very misleading.
As one of seemingly very few people that still buys CDs, they have become extremely difficult to find. Personally, I have to drive 90+ miles to the nearest store that sells them and pay a 25% markup when I get there, or order them off Amazon, in which case they always arrive with a broken case. I’m not counting Walmart because they only sell kpop and NOW cds. Target only sells kpop and Taylor Swift.
you’re probably lying or this is kind of placebo effect .
opus, with some exceptions, can reach transparency at even 150kbps (and of course you can and should go higer)
if the difference does exist it will never be “clear” to a human
Is ogg lossless? Just because you have limited hearing doesn’t mean there aren’t people who can hear differences. There are women who can see more colors than normal people (tetrachromacy). Assuming someone is lying because they aren’t hearing damaged is absurd. Also young kids have better hearing(less damage) than adults, hearing damaged from work or life conditions like traffic with windows down.
well if you need both recordings and an audio spectrometer to even notice the difference, it might as well not exist. good lossy compression is indistinguishable from lossless
<0.1% non-perceptible audio quality “difference” is not worth 500% the storage space usage, unless you’re archiving/preserving the audio and absolutely need the original bit-for-bit representation
if you’re just listening to it use opus, or in the worst case ogg vorbis
I’ve done the blind test before and 128k sounds the same as 320k, but flac and wav sounds clear and clean to me. IDK how people can tell the difference between 128k 320k (unless it was back in the day when encoding took longer and they used bad quality to save time)
Yes, i actually can’t listen to Spotify (even their HD) because the quality is so bad (sounds noticably bad to me). I pay for lossless streaming even though some indie music is not available on the lossless service so i go look for it on lossy services.
I’ve done this test before, a zip folder with all 4 sources all same file size and you can listen to them and note how each sounds then you can read which one is which later from another source
Yeah, the peripheral nervous system stops you from peeing when you’re rubbing up against clothing. An easy experiment is to put on pants, stand with your legs apart, and relax your urethra and pee. You still won’t pee because of the PNS signal from your crotch to your brain!
That’s bullshit I just pissed my pants and it went everywhere. It wasnt even hard to do. I’m sitting in a pool of my own piss so you sound really dumb right now.
As someone who knows someone definitely not me with a relevant fetish, can confirm. Sometimes it takes a surprising amount of willpower even after drinking an unhealthy amount of water an hour previous. Or so I’ve heard at any rate…
Ticketing people who don’t pay for parking is “bullying?”
This is pretty insulting to people who have actually suffered from real bullying. There’s plenty of real problems in the world to be righteously angry about. Maybe let’s not post shitty Facebook memes on Lemmy.
It’s meter cops who camp on your car in case your meter runs out before you make it back, so they can give you a full ticket for one second of “stolen parking”, you physicality thief, you.
I manage a machine that runs both media transcodes and some video game servers.
The video game servers have to run in real-time, or very close to it. Otherwise players using them suffer noticeable lag.
Achieving this at the same time that an ffmpeg process was running was completely impossible. No matter what I did to limit ffmpegs use of CPU time. Even when running it at lowest priority it impacted the game server processes running at top priority. Even if I limited it to one thread, it was affecting things.
I couldn’t understand the problem. There was enough CPU time to go around to do both things, and the transcode wasn’t even time sensitive, while the game server was, so why couldn’t the Linux kernel just figure it out and schedule things in a way that made sense?
So, for the first time I read up on how computers actually handle processes, multi-tasking and CPU scheduling.
As FFMPEG is an application that uses ALL available CPU time until a task is done, I came to the conclusion that due to how context switching works (CPU cores can only do one thing, they just switch out what they do really fast, but this too takes time) it was causing the system to fall behind on the video game processes when the system was operating with zero processing headroom. The scheduler wasn’t smart enough to maintain a real-time process in the face of FFMPEG, which would occupy ALL available cycles.
I learned the solution was core pinning. Manually setting processes to run on certain cores of the CPU. I set FFMPEG to use only one core, since it doesn’t matter how fast it completes. And I set the game processes to use all but that one core, so they don’t accidentally end up queueing for CPU time on a core that doesn’t have the headroom to allow the task to run within a reasonable time range.
This has completely solved the problem, as the game processes and FFMPEG no longer wait for CPU cycles in the same queue.
I think the difference is simply that most processes only have a certain amount that needs accomplishing in a given unit of time. As long as they can get enough CPU time, and do so soon enough after getting in line for it, they can maintain real-time execution.
Very few workloads have that much to do for that long. But I would expect other similar workloads to present the same problem.
There is a useful stat which Linux tracks in addition to a simple CPU usage percentage. The “load average” represents the average number of processes that have requested CPU time, but have to queue for it.
As long as the number is lower than the available number of cores, this essentially means that whenever one process is done running a task, the next in line can get right on with theirs.
If the load average is less than the number of cores available, that means the cores have idle time where they are essentially just waiting for a process to need them for something. Good for time-sensitive processes.
If the load average is above the number of cores, that means some processes are having to wait for several cycles of other processes having their turn, before they can execute their tasks. Interestingly, the load average can go beyond this threshold way before the CPU hits 100% usage.
I found that I can allow my system to get up to a load average of about 1.5 times the number of cores available, before you start noticing it when playing on one of the servers I run.
And whenever ffmpeg was running, the load average would spike to 10-20 times the number of cores. Not good.
That makes complete sense - if you’ve got something ‘needy’, as soon as it’s queuing up, I imagine it snowballs, too…
10-20 times the core count is crazy, but I guess it’s had a lot of development effort into parallelizing it’s execution, which of course goes against what your use case is :)
Theoretically a load average could be as high as it likes, it’s essentially just the length of the task queue, after all.
Processes having to queue to get executed is no problem at all for lots of workloads. If you’re not running anything latency-sensitive, a huge load average isn’t a problem.
Also it’s not really a matter of parallelization. Like I mentioned, ffmpeg impacted other processes even when restricted to running in a single thread.
That’s because most other processes will do work in small chunks that complete within nanoseconds. Send a network request, parse some data, decode an image, poll HID device, etc.
A transcode meanwhile can easily have a CPU running full tilt for well over a second, working on just that one thing. Most processes will show up and go “I need X amount of CPU time” while ffmpeg will show up and go “give me all available CPU time” which is something the scheduler can’t actually quantify.
It’s like if someone showed up at a buffet and asked for all the food that no-one else is going to eat. How do you determine exactly how much that is, and thereby how much it is safe to give this person without giving away food someone else might’ve needed?
You don’t. Without CPU headroom it becomes very difficult for the task scheduler to maintain low system latency. It’ll do a pretty good job, but inevitably some CPU time that should have gone to other stuff, will go the process asking for as much as it can get.
It was quite a while ago that I had heard the majority of internet traffic is from bots. I can imagine it’s significantly worse now, especially with publicly available AI bots.
I’m not huge or athletic but I probably weigh, like, twice as much as a goose. I get that they’re incredibly pissy and they have teeth and pointy bits, but I’m still betting on me.
In this context I think we have to assume life or death tactics by both combatants.
But that’s an important distinction because MOST of the time we deal with pissed off animals that we don’t want to hurt, much less kill. So that gives some animals a big advantage in real world encounters. Maybe most adults could kill a goose if they had to, but in real life 99% of adults are going to back off or run away rather than deal with a fucking goose!
Punt to the chest. Bird bones are papier mâché. Never get in a fist fight with a goose, their wings will break your arms. Definitely don’t try and snap its spindly little neck. Just kick it in the chest
lemmy.world
Top