 The T2 tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. So once again, we are up against the wall of science. I'm spending my time working on the scientific submission for the ALIF conference coming up this summer in Montreal. So as much as it pains me, I'm not going to talk about that with stuff right now. Instead, I'm going to talk about how to break ties and achieve synchronization both at a sort of fairly general level and then get all the way down to the nitty gritty of intertile events, which is the other task that I have to be working on. I spent about a day and a half plus a little bit on this and then it got some progress to show for it. But I think there's sort of some of the bigger philosophical picture that's important to understand why obvious traditional computer science and computer engineering solutions are not the direction that I'm going in. So normally when computers are going to talk to each other, you talk by a protocol, set a rule saying what to do. And the vast majority of protocols that are in use, like the serial peripheral interface SPI, I call it SPI, are designed to have a master and a slave and to make the two roles in the communication channel asymmetric so that it's clear who speaks first, who responds, who does what. And there's no race. There's no wondering about who gets to speak next because the protocol completely spells it out. And there it is. You know, SPI master, SPI slave, and so forth. And the vast majority, so token ring is another way of approaching this. This was invented by IBM like 30, 40 years ago, was used, not used a lot anymore. But now it's sort of a token, a special pattern of bits that was passed around among the machines that are sharing a communications medium. And if you had the ring you could communicate, I'm sorry, if you had the token, you could communicate. And you know, this made sense. It did work. It got some use, but it had all these aggravating things, like even if nobody wanted to be communicating except for you, you had to wait for the token to come all the way back around to you. And if something went wrong, God forbid, and the token got lost, then the whole communication thing stopped until somebody figured out that the token was gone. USB, I mean, a much more modern one that happens all the time. You know, you've got different, the cables, I have different connectors on the different ends, because you have a USB host and a USB client, a USB host and device. What are their differences? Are they really just the same? No, they're hugely differences. For example, the host initiates all communications on the bus. The host is usually the computer, your phone, whatever it is. And the client, the device is, you know, whatever you plug into it. You plug in a lot of things these days, you know, microphones, cameras, movie cameras and stuff, and they're all devices and they have to wait for the host to ask them. It's kind of strange and all that stuff just has to be worked out. These problems of communications order and so forth go way beyond just computers. You know, what should you do in the next time that you meet the Queen of England? Only speak when you're spoken to. That is a master slave communication protocol. Don't sit, she does and so forth. Now, of course, when I was googling around for this, it was like, you know, on royal.uk or whatever, it says, you know, there are no obligatory codes of behavior when meeting the Queen, you know, like, okay, obligatory and obligatory. But it's the same thing, to make everything go smoothly and avoid stepping on each other's toes and make everything seem as respectful as possible to at least one of the people in the thing. Versus that sort of master slave relationship, the ethernet in back in computer land is the big thing that at least originally was not that way. Like the token ring, the ethernet had a shared cable, it had a whole bunch of things that were connected to it and there was no master and no slave and any of them could speak at any time and it had this very clever technique originally used called carrier sense, multiple access with collision detection. That essentially means that when you had something to say, you just sang it out onto the wire, but simultaneously you listened to what with the wire was saying. And if you heard yourself singing, then you knew everything went through fine. Whereas if it comes back garbled, that meant somebody else was trying to sing when you were singing and there's been a collision. Now, and that's very clever and it worked quite well and it got ethernet off of the out of the box and made it essentially the winner that, you know, it's become that A for hard lines. And these days, everything's been broken down. So pretty much every pair of things that are talking have their own specific wire to talk to, rather than having lots of device sharing a party line. So this collision detection business has gone away in full duplex with switches. So modern ethernets are completely collision free. Oh, of course, that doesn't mean everything is wonderful because there's still the only so much data that you can push through a wire at a given amount of time there. It means the arbitrage between which packets get to travel between the switches and so forth still has to be sorted out and things may have to wait. So there's no collisions, but that doesn't mean everything flows perfectly. The internet has the same sort of issue at the next level up. The TCP, the transmission control protocol is the way that you talk, the way that your computer is your phone talks with everything when you go to Facebook, when you talk, make an IP phone call and so forth. All of this stuff, well, almost all of it, is going via TCP. There's another possibility. But in TCP, in order to begin talking, there's this thing called the three-way handshake. And it says, the client says, I would like to talk to you. And here's my piece of information saying my little sequence number, where I'm coming from. And the server says, I heard you say sequence number X. And here is my sequence number Y. And then for the third part of the handshake, the client says, I heard you say sequence number Y. And now we are off to communicate back and forth. And we keep using those numbers that we exchange in the three-way handshake to keep track of what has been received at each end. The problem being that things take time. You can have packets crossing mid-flight. It happens all the time. And you have to somehow sort this out. So the three-way handshake is a clever thing. It works very well. But you have to understand that isn't this like the same, the whole philosophical, those logic puzzles where the natives have blue eyes and green eyes and they have to leave the island if they have green eyes and so forth. So it gets into these things, I know that you heard me. And you know that I heard you. But you don't know that I know that you know that I know that you heard me like that. And in fact, people don't think about it because the three-way handshake works perfectly well for most cases. But in fact, if you go into it, that yes, we can't actually prove that all the packets got through. Because that last hack, the client is going to send more stuff after that last hack. But that last hack, it doesn't know that the server has received it or not. In fact, you'd have to send an infinite number of sins and acts back and forth. And in fact, TCP kind of does that by using the actual data packets to acknowledge previous ones as it goes forward. But it just goes to the show that there is not sort of a permanent 100% guaranteed bulletproof solution to this. There's just stuff that works well enough. And when it comes down to letting things. So in TCP, it's OK because the client speaks first. It's always the client going to the server saying, I would like my home page. I would like to see my email, whatever it is. And the server says, OK, who are you? And off they go. But there's a lot of cases where there things can be absolute races that can have absolute ties and you have to have some kind of tiebreaker. Now in computer science, traditionally, people think ties are unlikely, so they don't matter. So for example, if you're comparing two numbers to see which one is bigger, you say, well, if A is bigger than B, then do whatever. If B is bigger than A, then do something else. Well, but what if they're equal? So do you let A get it? But A and B are supposed to be the same kind of thing. Why does A get the special little case of when they're equal? And so, right. So tie goes to the runner. That's the sort of idea of it. If in baseball, if the runner is running towards first base and the ball is coming and the first baseman catches the ball at the exact same time that the runner tags the base, then the tie goes to the runner. Well, of course, I learned by reading up for this video that the umpire say, no, no, no, that's not true. Strictly speaking, there is no tie. You know, either the ball hit the glove first or the foot, the toe hit the bag first. And whichever that one is, that's the correct call. And you know, I understand how it seems to make sense to go with that, you know, that there's no official reason to admit that the world is fuzzy and that all the way down at the femto seconds and quarks and whatever, you'd figure, you know, well, one of them must have happened before the other one. But if you go down that road, it has all kinds of bad effects. And the one that comes to mind for me is this idea of high frequency trading. And there's lots of different forms of high frequency trading, but one in particular is called low latency strategies. And the idea is if you can get your bids, if you can get your orders into the stock exchange ahead of somebody else, you can make money. If you both have access to the same information that you can react first, then wow, you get the good price and the next guy gets the price. It's already been jacked up by your order. And people haven't gone crazy with this, you know, using microwaves versus wires because it's faster and building buildings right next to the stock exchange to have the minimum amount of wire to do it and so forth. And, you know, this strikes people as, you know, how is this really fair? And, you know, in a big sense, it isn't and it leads to this, you know, the new standard for price. This looks like an ad for, you know, a rack-mounted 3D printer, some sort. No, it's not. This is three spools of fiber optics that compile, that together, they're just hooked together so that it's something like, you know, 38 miles, 36 miles, I'm not sure. A ton of fiber-optic cables and a stock exchange, a particular stock exchange, the IEX, the Investors Exchange, takes all of the communications coming to their stock exchange and routes it through these dozens of miles of fiber optics deliberately to slow it down. Now, that doesn't change the order of how they come in, they arrive in, as all those things are sipping, sipping, sipping, they pop out again the other side. But what it does is it means if you're racing with the outside world and some tiny little amount makes a difference at the exchange, well then the information will be stale by the time it pops out the other end of this magic box. And in fact, they now have data. The intentional access delays make the IEX a fair exchange. This particular paper did a bunch of studies on it. So going as fast as you can, not admitting that you need to break ties somehow, that you can't just leave it up to the physics and expect things to come out right is the takeaway message. And you know, in computer science, you see all of these things, in specs and program stuff, saying break ties arbitrarily, ties are broken arbitrarily. And what that really just means is you're not taking responsibility for the consequences of breaking ties one way versus the other. And for computers, for typical computers, lots of times it doesn't matter, but for adaptive systems, it often matters. And this is what we see over and over again in artificial life and living computation systems that they will evolve to get right there at the edge. You know, it's like you'd rather win the auction by one penny rather than a million dollars. And if you're engaged in auctions over and over and over again, you'll hone in on being that A guy versus that B guy and getting the floating point number that has one more thing in the 16th digit so that you can win for the cheapest price. And again, that's just like the high-frequency trading. It's no more fair here than it is there. And in our systems, it causes all kinds of strange behaviors where, you know, your creatures tend to move up and to the left of the screen. Why? Because you've you visited all the sites that they were getting updated in a fixed order, which was breaking ties arbitrarily. And again, it's not arbitrary. If you say it's arbitrary, it means someone else knows what it is and you don't. So this is where we were. Our T2 tiles are all completely symmetric. There's no reason to say one should be the master and one should be the slave. And you might say, okay, well, you know, I'll make West, Northwest and Northeast be masters and Southwest, Southeast and East be slaves. Done. They all match up that way. It'll be one master and one slave, but it isn't because now if we haven't got a guy to our Northwest, we have no master, but we still need to communicate with other folks and so forth. And furthermore, if you're the master, you have this little bit of edge because you get to speak first, you get your stuff to ship through, and it's really, really hard to wipe that out. So the goal of the intertile event sequencing system is all about how to get this going without resorting to those simple-minded master-slave relationships. And so the way I'm doing it is I'm making these levels. There's the initialization level. There's the level when we've discovered we're doing MFM and we have compatible MFZ files. And then there's that we're actually doing events and so forth. And what I'm mostly focused on and the stuff that I've worked on this week was the first levels, getting it up in a systematic way. And it's starting to look okay. So we have three levels and in each level we have three stages. When we first got in, we are here, but we're waiting to hear that the other person is here. Now we're in the stable position. We are here and we've heard that you are here as well. And then when the world changes on the state of the tile so that we're ready to move on, we go to the third stage, saying I'm ready to move on to the next level, but I haven't heard that you are. And as soon as I hear that you are, then we move on to the first stage of the next level. And it works pretty well. Oops, all right. So here it is. So this is another curses simulator. Now we've got the tiles have been sort of shrunk down because they're not so important but the intertile connector. So this is the west connector for the tile A guy. This is the east connector for the tile B guy. And then we have two actual channels in between them. And so if we let this thing run what happens is the ITCs gradually start to build up the stack. The first step is in it enter. And then when they realize that both sides are in it enter they move on to in it stable. And then they're gonna move on to in it exitable once their tile has started running in MFC. Oh, so in this case we lucked out. Tile A and tile B are both running MFC zero. So those are compatible. So we should get all the way up to compatible to compatible enter and we should get to compatible stable and there we are. And so that's a case where it all worked great. Now I've designed these tiles so they completely randomly shut down and start up other MFCs at various times. So I won't take a lot of time to look at this but we can speed it up until somebody screws up. All right, so that's all right. So now we have what do we have? No, we're not. Okay, so there it is. Now we have MFC one versus MFC zero. So tile A is running MFC one. Tile A is running MFC one and tile B is running MFC zero. And now they're stuck at in it exitable like that. And they will send redundant packets because things may cross in the mail. If everything works out right and the timing gets all set about right it'll actually be fairly efficient. One guy'll go, the other one will respond and they'll move on but it'll be much more robust and I'm feeling pretty good about how this shape is shaping up. So I need to polish this up more and clean up the code to then use it as a model for going back to the C++ code. And that's what I would really like to get to the point of this coming week we shall see. All right, so four more weeks in the wall of science sequencing intertile events. The sequencing is coming along. Hope to have more next week. Thanks for being here. You have a good week. Hope to see you next week.