 Hello everyone, my name is Olexia Rampel. I am working at Pilgrotronics. And most of my hacking time, I am doing things related to networking and kernel stack, kernel network stack. And most of our recent projects I was working on are kind of related to different type of industries, medical devices, agricultural devices and so on. So I gathered some of this experience from this project and picked up some of the topics which I think are kind of interesting from environmental point of view, like technologies which help to reduce some kind of footprints on one or another side. For example, to reduce the amount of energy needed to accomplish the same task, like for example, your running network and using less energy is always a good idea. Or for example, if we used one gigabit link, why not use a bit less copper needed for the same task or something like this? So I chose this kind of technologies. And in this case, our single pair ethernets, which is, well, it says for itself, it is using only one pair compared to different kind of ethernets. I don't know how many of you are actually know about single pair ethernet. Can you rise to that? Oh, cool. It is much more as I expected. And are they actually people working in companies which are making hardware for single pair ethernet? For example, five switches or something like this? Anyone? The Texas Instruments, analog devices? Yeah, yeah. So just raise your hand if you have questions, then there's analog devices here. Well, except of just using single pair ethernet, you can use next level of this technology is the power over data line, which is kind of like power over ethernet but optimized for single pair ethernet. I don't know anyone of using it already. No, okay. I'll tell some words about this. And last but not least, energy efficient ethernet. I have noticed it's kind of broken. How many of you are using this? Okay. Is it working for you? I mean, how many of you are disabled on purpose? Okay. So the last part of this talk will be about how to use tools with kind of limited budget and debug energy efficient ethernet. So you'll be able to get hands dirty and probably fix some drivers. There's a lot of fixing needed. So I'll hope this part of talk will help you or at least a kernel. I have noticed, I have, well, except of just working and doing things for other customers, I love to hack myself under their printers and things. And I think this kind of technology is really usable not only for automotive or industrial things, it is really usable for hackers and makers. So I hope this technology will really find the way to this scene. For example, in my case, I will be really able to optimize my dry day printer just by using only two cables instead of like thousands. So some words about single pair of ethernet for people who don't know how this works. The first picture is 100 base TX, which is using one twisted pair to transmit and other twisted pair to receive this part. And well, it is not really optimized and not really good for using this kind of technology inside of cars, a lot of weight and so. And in case of 1000 base TX or gigabit ethernet, we'll have four twisted pairs which are used at same time for transmitting and receiving. So if we are able to use same twisted pairs for transmit and receive, why not optimize it and use just one twisted pair for transmitting and receiving but with higher speed. So this single pair ethernet is actually about this kind of optimization. And suddenly it is not backwards compatible to existing technologies and you just can't drop in and make it work for everyone. And this kind of technology was optimized for many different tasks. For example, if you'll see something like 110 or 1000 base T1, it means it's mostly optimized for automotive. It will be pre-configured and will create the link as fast as possible. I don't know how many of you have experienced by plugging the ethernet cable and it takes seconds or tens of seconds until the link is created. And it is not acceptable for automotive. You should create the link as fast as possible within milliseconds. And in this case, it is already have pre-configured speeds and rolls. There is no possibility to have on one side 10 megabit and another side 1000 megabit. It is already fast for configured and there are pre-configured rolls like master and slave roll. So in this case, the link speed will... Link creation speed is really fast. And if you'll see this kind of suffix at the end of description, for example, L or S, L is for long range. In this case, for example, if you'll see 10 base T1L, it is single pair ethernet for long range. Very good as a replacement for kind of fuel boost or can boost and some industrial or home automation cases. The length is like 1000 or 2000 meters in some cases. And there is even some optimization for explosive environments. So you'll be able to reduce the signal amplitude. So things should not explode in this case. And if you'll see this S at the end, it is for multi-drop links. In this case, you can create a link with multiple devices on one cable like with can. So you don't need switches for this. It is practical, but there's all of this optimization. They are not for free. I mean, you should drop something. For example, for fast link creation, we remove out the negotiation. So it can't just combine different devices and they will find out what is used for what case and so on. Or in case of long range, well, I don't know what is actually... Well, we reduce the speed. For example, it is not possible to have 100 base T1L, which is 1,000 meters long. I think this... I don't know... Analog devices don't know about 100 base T1L. Or there's... What kind of limitation? We have 500 meters? Okay. So why should anyone replace existing infrastructure like canbus or bus... Philbooth to use Ethernet instead of this? It usually depends. And it's really hard to argue in different cases. For example, I have talked with BMW guys here making automotive things. And it is... In case of... It depends on how much CPU power and how much software stack you are able to get in your controller. If you have a lot of CPU power and you can implement IP stack inside of your application, then it is probably a good idea to take Ethernet instead of can. If you really have some limited CPU, limited RAM, then in this case, it is really a better idea to still have can instead of this. For some applications, for some customers I have seen that it is good to still run IP because you have different connections. You have Wi-Fi, you have LTE. And if you're already doing a lot of IP, then converting into can is not really optimal thing. And compared, for example, with can, we already have some standardization passed for this or a lot of already created infrastructure which is accepted for different kinds of applications like PTP or quality of service and so on. So you'll be able to get this kind of for free with already tested and implemented infrastructure. In case of can, using PTP, I don't know, I didn't see an already implemented standard or at least in case of Linux, I haven't seen open source implementation which is standardized, which is implemented according to some of standard. So is it complicated to make new devices with single-pay internet? It depends. Well, our hardware guys was able to glue T1L5 to some existing A6 USB to Ethernet converter. So this is one of examples how this can look like. It works. We needed some iterations with kernel to make things replaceable. For example, many Ethernet drivers do not accept some kind of different files and there was a lot of assumptions, bare assumptions, which needed to be fixed. And if this is done, then you can just replace the file and to use any existing Mac combined with this file. So I tried to compare different projects, which I was working on and ask people why are they starting to use single-pay internet? And for example, in case of medical devices, there are at least projects I working on are migrating to Ethernet because, well, there was different kind of pre-existing proprietary protocols. And it is hard to keep them running on new kernels and keep things secure with new kernels or keep things secure with old kernels. So they need to run some kind of mainline thing. And Ethernet is the way to go. So migrating to Ethernet is the first step and migrating to single-pay internet is the current next step. So for example, imagine medical device monitoring health status of patient, which has, well, less cables and needs just smaller connectors. In case of industrial use cases, there are different customers I was working with. And they migrating from can where possible, main challenge is to keep things as cheap as we can. In some cases, it is really possible. So they have some, I will show some pictures of existing switches which running with power or data lines or they are providing power to sensors or to actors. And it is kind of nice to reuse existing protocols and reduce maintenance overhead for these kind of devices, especially if they are connected to internet somehow. They are in dangerous part of IoT where things should be updated and secure. So keeping things mainline is really easier for many of them. Same about agriculture devices. In this case, I'm talking about kind of tractors or harvesters running on fields with existing can protocols. Well, agriculture is kind of close to automotive but with different kind of restrictions. And they are using many existing protocols like easel booths and so on, but all of them are slow. I mean, can is slow. So using single-payer internet is, well, way to go if it's possible. And some of projects are migrating and trying to give some hybrid implementations like parallel can and single-payer internet over the same can-twisted pair. So, for example, if devices are from the same vendor, then just switch from can to single-payer internet if possible. So in all of these fields, at least for me, I don't know if you have this situation, you have seen similar patterns and then you see it everywhere. Like I was working with single-payer internet with some customers. Now I see it's like everywhere. So it looks for me that there is kind of trend to migrating to single-payer internet. And well, it seems to be a way to go for many reasons like easier to maintain, easier to test. For example, if we use internet controller, it is most probably already tested by many different projects. So we will just replace the file and still most of this software stack is tested with different projects. Compared with can, it is more like really restricted or some special use case not really seen by many projects. So as next, I will show you some info about Power Over Dataline, if you don't know it. I assume you have heard about Power Over Ethernet. So usually in case of Power Over Ethernet, we use one twisted pair for example for plus and one tested pair for minus. And in case of Power Over Ethernet 4, we use all four twisted pairs to provide power. And in case of Power Over Dataline, there is a different challenge. So we have only one twisted pair and we need to use one wire for plus, one wire for minus. And in this case, to filter your signal is a bit more difficult compared to Power Over Ethernet. So it will not be because compatible with Power Over Ethernet devices. And it's compared to Power Over Ethernet. It's still hot-pluckable and you will be able in most cases to detect the device which is connected and you will be able to classify the device. Usually you should be able to see like, okay, device which is attached, it will need some amount of, some budget of power. And from the switch point of view, it should be able to be able to resolve this amount of power or not to enable this device. So Power Over Ethernet is using resistor or voltage drop or whatever technologies. And for Power Over Dataline, we are using SCCP which is kind of like one wire communication protocol. And in most cases, most important questions like if you are talking about mainline things, is it implemented? Is it mainline? Yes, it is already, at least in case of Power Over Dataline, it is already mainline. You should be able to use ETH tools to control power just on top of your net link. For example, in this example, I'm listing all available interfaces. And in my case, there is T1L1 interface which is currently not enabled from network administrative point of view. And with ETH tools, we are able to see if this is actually providing power and it shows no. It's not providing the power. And you're able, independent of actual network status, enable power. In this case, you'll need to use this command. And well, voila, it will work. All of these paths are already mainline. You will be able to use current Linux kernel 64 and ETH tools 6.3 with all of these commands. And this should work. But you will need to use the drivers and device reconfiguration to make all of these paths work. Here's one example of real hardware. This is switch using T1L standard. And as you can see, connectors for T1L are usually tiny compared to normal internet, like RG45. And this switch is providing power over data line. And this part is actually one of sensors or actors using this power and using this connection for data transfer. So now is the next part, which is related to energy efficient internet. And like I said, I started investigating this because it was kind of broken for me. I tried to synchronize some boards with PTP to synchronize as close as possible. And it didn't work. So I started seeing what's actually happening. And actually, this device, which I was using, should not use energy efficient internet, but it was using for some reasons. And well, I started investigating this. First of all, I had some issues with hardware. What kind of tools should I use? What's how expensive will it be to investigate this kind of issues? And current kernel states was like, it needed a lot of work. Most of cases, we was able to see that energy efficient internet was kind of misunderstood. So what kind of problem is usually present in most of drivers? Typically, if we start connection, then connection will exchange authentication information about link and capabilities. And usually, one side should say, hey, I am supporting energy efficient internet for different kind of links. And other side should see this and say, OK, I am supporting this too. And after this, after link is created, Mac drivers should actually enable this. And voila, it's working. But reality was kind of different. Many Mac drivers was enabling energy efficient internet before link was created, or was enabling energy efficient internet on probe, which is kind of weird. I mean, it won't be able to decide and link if it's shunt run or not. So it will accidentally work in some cases. So to see if it's actually working, you'll need an oscilloscope, at least. And usually, if you start investigating this kind of issue, you'll probably find that debugging internet with oscilloscope can be very expensive. I mean, to get an oscilloscope which is capable to run at this speed will cost you probably at least a car, maybe a house. And you'll need very good oscilloscope. You'll need to have differential probes, which are expensive as hell. And yes, it is possible to reduce budgets if you will reduce at least your target. For example, to see if energy efficient internet is actually working, it is enough to have at least 200 megahertz to hear samples. So it's like budget is dropping to about 1,000 euro. Maybe you'll be able to see the same picture even with 100 megahertz oscilloscope. So you'll be running like 300 euro. To kind of replace and be careful here, it is not possible to replace differential probe. But if you know your setup and if you're careful enough, you'll be able to have some resistors and create this kind of voltage divider. And in this case, you'll be able to see some signals and make it work for this particular use case. And you should not use power over data line for debugging in this case or power over Ethernet. So instead of creating some extra complicated hardware, I just took one of our Ethernet debugging helper tools, picked some resistors. So this is kind of end configuration. You will probably do it even with other stuff. And first of things which you usually start to fixing, it is usually not properly implemented or not implemented at all. MDIX or Automatic Cross-Over Detection. Usually it is not implemented because nobody cares. I mean, it works, so why should anyone implement this? But it will make your life harder if you want to debug some things like energy efficient Ethernet. So it will be good if you will be able to make things predictable. In case of Automatic Cross-Over Detection, you'll have this kind of pulses on both twisted pair lines. And this is auto-negation pulses. They are actually transferring information about files from each side. And to make Automatic Cross-Over Detection work, files will transfer these pulses on different lines. And this is actually not what you want to have. To make it with ATH tools, you should be able to configure, you should be able to disable Automatic Cross-Over Detection. But if you get a picture like before, after running this command, like ATH tool, Advertise MDX on, you should actually get this picture. If you don't get this picture, it is not working for you. So you'll need to fix first this part of FI driver. As soon as this part is fixed, we can start to investigate what is actually wrong with energy efficient Ethernet configuration. Usually, if you run this command, ATH tool show EE status, then you should get some kind of information like state, this active state. It is enabled means from administrative point of view. I kindly ask the system, please enable energy efficient Ethernet if you can. And active means, OK, the system decided that it is enabled. And we can enable this. So we're activating this. Then we have transmit low power idle timer, which says after we transferred some data, for example, we're transferring some pink or whatever. After this time, this is 500 milliseconds, we should be able to drop and switch to low power idle mode. And if all of this properly configures, and our link partner says, or we says, we are supporting like energy efficient Ethernet for 100 base T full or 1,000 base T full speed. And link partner provides the same or similar configuration. Then we will be able to enable energy efficient Ethernet for matching configurations. If it's activated, and if it's working, you'll get this kind of picture. It means here, all of these pulses are kind of keep alive pulses. And after keep alive, you will drop power consumption. And mostly, you will not see any signal in there. And if it's disabled, you'll see it's like this. So you should be able, if energy efficient Ethernet is enabled, you should be able to see this picture. And if it's disabled, you'll see this picture. And if your expectation and picture do not match, you should start fixing it. So one more comparison. It is possible to enable energy efficient Ethernet only on one side. For example, if you are running 100 base TX, and one cable is for TX, and another is for RX, you should be able to say, OK, our site supports EAA modes. So you'll run it. And other sites do not support it. So you can combine these two modes. But at least I don't know if it's actually working for gigabit Ethernet, but at least it is working for 100 Mbit Ethernet. If you now under control of this configuration, now you should test if timer configuration, like for example, at the start, you have seen Elix timer was configured for 400 milliseconds. We should actually get this kind of image if we are running, for example, if we are sending in some packet. If timer configuration is kind of broken and there is sometimes broken for different reasons, for example, the clock tree is not properly configured and you are running at wrong time up account, then you'll get wrong results here. Otherwise, like I said, if the system is configured for 500 milliseconds, we should be able to measure here something about 500 milliseconds. And in case of gigabit connection, you'll be able to see the same picture but for all of twisted pairs like this. And you should actually test different modes because sometimes we have different clocks for different link states. Like for 1000 Mbit, we probably will run with 125 MHz, for 100 Mbit, we'll probably run with 50 MHz. So it is good to know if all of expected link configuration are actually working. Currently, I have started a discussion about current state of ES support and there are a lot of patches flying around. So maybe some of issues will be fixed soon but I'm pretty sure there are still a lot of things to fix. I hope you'll be able to measure it and make things work. Related to a single pair Ethernet at least at state of kernel 6.4 RC1, most of things are mainlines so you should be able to just use it at least for Texas Instruments and Analog Devices files. The same is about T1S standard which is at least partially supported. Some of configuration is provided for H2Ls. And Power Over Dataline, I started kind of framework to handle Power Over Dataline on Power Over Ethernet things but it's only initial state. It supports currently only simple configurations and simple hardware. I hope we'll be able to support more complicated controllers soonish if there are customers or if there are some other developers who will mainline patches. Yeah, this is current mainlining state of this kind of technologies. Do you have questions? Thank you. For the single pair Ethernet and question is do you need to connect to RJ45 via a switch or if you have a special cable can do one side single pair Ethernet and the other RJ45? Moment. So this example, yes? Yeah, both sides are both SBE. But can you do one side SBE, the other side RJ45 or you always need a intermediate switch in between to connect to the industrial switch? You can combine standard Ethernet and single pair Ethernet before any media converter. So you probably will need some kind of switch or media converter if I understand your question. There are chips with Mac and Fi incorporated in one chip and doing done SPI. Is there any work done that these two layers, they don't fit really good into the Linux kernel that this open alliance layer for the Mac is implemented? I know at least one controller which fits to your description from analog devices. It is mainline. I don't see a real problem with it. What kind of problem do you see? OK, probably I misunderstood it. But also on the mailing list there was the question from Microchip to separate these two layers. And OK, probably we have to talk later about it. Yeah. Do you know different protocol called broad air reach and how it differs from hundreds base T1? Yeah. And what are the pros and cons of using one or the other? As far as I know, 100 base T1 is actual end result of standardization. And broad reach was kind of probably pay state of standardization. So there may be some timings differences. But so far I was not able to see real problem to combine these devices. Maybe I don't know if someone have experience with this. Please say. But so far it was kind of working. I don't see any big issues with it. Time's up. Thank you very much. Thank you.