4 ms·
What happens when two 802.11 devices use the frequency at the same time? I was under the impression that they'd both re-transmit after a arbitrarily chosen paus
by iso8859-1 3y ago
What happens when two 802.11 devices use the frequency at the same time? I was under the impression that they'd both re-transmit after a arbitrarily chosen pause. If that is true, time would be a de-synchronization primitive. Then, it is surely also a sync primitive.
How do you arrange a date with your friend in the city? I usually say "let's meet at 17:00 at the main train station, under the clock".[0]
You have to know your counter-party's accuracy. But if you synchronize on any other metric, surely that could also be inaccurate? So how is time any different?
[0]: Note: in Danish: https://www.berlingske.dk/under-uret-uret-skiftes-ud https://www.berlingske.dk/under-uret-uret-skiftes-ud
- CyberDildonics 3y agoIf that is true, time would be a de-synchronization primitive That's not desynchronization or synchronization. The synchronization is realizing they are both trying to connect at the same time. How do you arrange a date with your friend in the city? I usually say "let's meet at 17:00 at the main train station, under the clock".[0] The conversation is synchronization here. Synchronization is unambiguous communication.
- xyzzy_plugh 3y agoSynchronization is inherently temporal. The "chron" in the word even means time. Synchronization is unambiguous communication with respect to some time coordinates. It's certainly possible to communicate in a way that appears to be unambiguous without explicitly referencing time, but the time is always implicit. Practically, all communication is otherwise ambiguous.
- CyberDildonics 3y agoSynchronization is inherently temporal. Everything happens over time Synchronization is unambiguous communication with respect to some time coordinates. No, it could mean ordering but that doesn't mean 'time coordinates'. It's certainly possible to communicate in a way that appears to be unambiguous without explicitly referencing time That's because time isn't the most fundamental aspect, reading shared information and ordered writing are. If cars need to merge on the highway into one lane, the space between them isn't the most important aspect, deciding on the order is. There could be a little or a lot of space in between and it still works.
- xyzzy_plugh 3y agoOrdering often is temporal. "Two comes after one" implies that "one" is somehow before "two" but the word you probably mean is "greater than." In the case of cars, saying "the blue car merges first, and the green car second" implies a temporal ordering of events. That again is time. We implicitly know that the velocity of the car and anticipated changes in acceleration impact when the events will occur, but they are implicit. We inherently know that it's ridiculous for the green car to merge a nanosecond after the blue car, but we're assuming a velocity. Time is present everywhere that there is change. Synchronization tends to involve changes.
- CyberDildonics 3y agoAgain, just because time is 'present' doesn't mean that 'time is a synchronization primitive'. Programs execute over time, but synchronization is not fundamentally about when things execute, it's about the order that they execute. The order is what is important, not specific time coordinates or specific timing. Just like cars merging, where they go in absolute space is not the fundamental concern, it is where they are relative to each other so they don't overlap. Synchronization is about serializing events if they have overlap in the data they affect.
- packetlost 3y agoOrdering is a subset of temporal though. That is, ordering implies there must be a relative time between events. Absolute time doesn't have to matter, nor does time between events. It's still temporal.
- CyberDildonics 3y agoOrdering is a subset of temporal though. That is, ordering implies there must be a relative time between events. Absolute time doesn't have to matter, nor does time between events. It's still temporal. It's only temporal because all execution is temporal. The fundamentals of what you are trying to achieve aren't when something executes, it is the order. If try to execute two different things at two different times, your synchronization could go wrong because that isn't really what you want, you want a guarantee of the order. If you try to synchronize by guaranteeing the order that operations execute it will work regardless of what time something executes. Ordering is what you are actually trying to achieve, timing in ancillary. That's why the title is 'time is not a synchronization primitive'.
- Brian_K_White 3y agoAll this means is that time exists. No one tried to say time doesn't exist. They said it was the wrong tool for the job. Time is a side effect or consequence of the ordering of events, it does not cause, enforce, or predict the ordering. One thing depends on some other thing. It does not depend on the passage of any particular amount of time.
- deleted 3y ago[deleted]