channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=5&d=8
12:00:00 <zid> no scans, no irish, no dogs
12:00:38 <geist> linear scans, psah. <spits on ground>
12:04:31 <eryjus> that did it, thanks for the pointers
12:10:55 <doug16k> has anyone found multi-monitor stuff in uefi API?
12:18:25 <doug16k> it says nothing because they expect you to just enumerate all objects that implement EFI_GRAPHICS_OUTPUT_PROTOCOL?
12:31:45 <doug16k> if I get it to find multiple monitor framebuffers, then my uefi bootloader will be one iota better than bios one
12:32:09 <doug16k> I want to see how many times faster my fat32 code is someday
12:32:16 <AerodynamicBrick> You guys seen the sad state of affairs on the osdev discord?
12:33:02 <doug16k> no
12:33:41 <AerodynamicBrick> Best to keep it that way q.q
12:35:09 <CompanionCube> there's an osdev discord?
12:35:55 <AerodynamicBrick> prepare yourself for overbearing inclusiveness
12:36:09 <AerodynamicBrick> exclusiveness rather
12:37:06 <doug16k> both sound bad :)
12:37:11 <CompanionCube> ooh, are they douchesnozzles?
12:37:28 <CompanionCube> that came out wrong
12:37:35 <CompanionCube> s/douches/douche/
12:37:48 <doug16k> both sound bad :)
12:37:49 <AerodynamicBrick> it seems the ego of the younger LL devs has turned into a better-than-you attitude
12:38:15 <AerodynamicBrick> Everybody feels a little cocky sometimes working so LL, but its run away fast down there
12:39:57 <CompanionCube> how so?
12:41:00 <geist> well, frankly, what happens over there is of no concern
12:41:08 <Mutabah> I have heard that the discord is not a nice place, but haven't had the time to investigate.
12:41:09 <geist> if there's some drama in another osdev forum, we dont want to hear about it
12:41:16 <Mutabah> +1 geist
12:42:21 <geist> we've had spin off irc channels, slack, forums, wikis etc. but freenode irc remains
12:43:12 <AerodynamicBrick> tldr: small niche interests create small niche cliques with mutual inflation
12:43:28 <AerodynamicBrick> Thank god for IRC
12:43:46 <doug16k> that the thing about ponds
12:43:49 <geist> indeed. though we could also be dicks, but we just try not to
12:43:55 <doug16k> you can create one, jump in, and be the biggest fish
12:44:03 <geist> and i'm fairly happy that we i thik are doing an okay job at it
12:44:58 <AerodynamicBrick> I've been happily stalking here for a year now
12:45:03 <AerodynamicBrick> things seem to be alright
12:46:10 <geist> cool. its only what we make it. it comes in waves. sometimes more interesting, sometimes quieter
12:46:20 <geist> but i think we generally speaking at least try to treat each other nicely
12:47:25 <AerodynamicBrick> who runs #osdev
12:48:57 <geist> no on in particular
12:49:00 <bcos> doug16k: For multi-monitor UEFI; I think the general idea is to use "LocateHandle()" to get a list of handles that support GOP; then do a "foreach(handle) { openProtocol(); }"
12:49:14 <geist> it's been here for about 20 years, 'ownership' sort of transfers over time
12:49:21 <bcos> AerodynamicBrick: What is an "LL dev"?
12:49:34 <geist> low level is what i think
12:49:35 <AerodynamicBrick> just abbreviating low level
12:49:36 <Mutabah> bcos: Someone who develops parsers :)
12:49:58 <bcos> Erm, OK :-)
12:50:18 <doug16k> bcos, thought so. going to extend my qemu launcher to configure a multi-head spice vm and see if I can get an array of framebuffers going
12:50:57 <geist> doug16k: the virtio-gpu stuff i think easily supports it. i think you may be able to create more on demand, perhaps
12:51:07 <geist> but i seem to remember it has the concept of multiple scanouts
12:51:14 <doug16k> yes
12:51:32 <bcos> doug16k: I wouldn't be too optimistic - from what I've heard real computers struggle to support things properly and the "OVMF"/tianacore firmware that most virtual machine use is far worse
12:52:17 <geist> as far as i've seen i've never seen any UEFI implementation bring up more than one head at a time
12:52:26 <bcos> (I think half the real video cards out there don't support UEFI and the machine's firmware uses VBE behind the scenes as a temporary "just make it work" measure)
12:52:29 <geist> and the display it decides is the main one is fairly arbitrary
12:52:57 <geist> bcos: while i think that may be true, i dont see that there's any strong evidence of either statement
12:53:12 <bcos> geist: I took a peep at Zircon's framebuffer code and.. it doesn't even try to multi-monitor
12:53:24 <doug16k> perhaps with vendor semantics (nvidia enables one, blackscreen the rest, amd defaults to put same thing on all screens)
12:53:33 <geist> probably the right way to determine it is to break into a uefi shell and poke around with the drivers
12:53:57 <geist> see what the device/driver state is. it might show whether or not there's a nvidia/amd/intel specific driver that has initialized the display
12:54:29 <doug16k> it would be the video card bios bytecode thing driver on a nice discrete display card right?
12:54:38 <geist> hypothetically as the CSM is generally turned off, it isnt even there long enough to run the classic video bios. there's supposed to be the new bytecode stuff
12:54:55 <geist> right. question is whether or not that's actually what's happening
12:55:13 <geist> for builtin video you could assume the motherboard includes a copy of the driver
12:55:52 <doug16k> essentially same old though, some option rom has some magic struct and it gets used
12:56:31 <geist> yah. the one example of something i've seen that works that may be an option rom is a discrete intel nic plugged into a machine with only built in realtek. uefi instance brought up the intel nic too
12:56:34 <doug16k> but ya I see what you mean, part of MB
12:56:36 <geist> unclear where the driver came from
12:57:02 <geist> could be in that case the MB rom just has drivers for a bunch of common stuff. intel nic is about as common (aside from realtek) as it gets
12:57:36 <doug16k> too bad they didn't formalize the nic spec like ahci and stuff
12:57:45 <geist> i found no evidence that the intel nic had a rom, but then i have no idea what i'm looking for
12:57:53 <zid> intel nics tend to
12:57:58 <zid> I don't know if they boot though
12:58:03 <doug16k> rom will stick out like a sore thumb in pci config I think
12:58:20 <zid> It's got a copy of the mac in it and stuff, at least
12:58:25 <geist> right, unless there's a switch you set that causes it to dissapear byt he tiem linux sees it
12:58:34 <doug16k> ya, that
12:58:35 <zid> and there was that linux bug where they overwrote past the end of the mmio region and garbed the roms on intel nics :P
12:59:23 <geist> possible. i haven't seen precisely in the uefi spec where it specifies how one produces a PCI-e device with a uefi rom
12:59:38 <geist> presumably you export one via the usual rom pci stuff and then there's some structure you put there somewhere
12:59:44 <geist> but i didn't see precisely where that's specified
12:59:54 <zid> I'ver never looked at how option roms work actually
01:00:00 <geist> could be even less structured than that, like if it's at offset in BAR0 or whatnot
01:00:05 <bcos> I vaguely remember seeing something about ROM containing multiple images (e.g. with headers, etc) so a card can have one for BIOS, one for EFI byte-code, one for EFI native code, etc
01:00:13 <zid> I've never booted uefi, but my graphics card has a splash screen etc
01:00:20 <bcos> *a card's ROM containing
01:00:34 <doug16k> this? https://edk2-docs.gitbooks.io/edk-ii-uefi-driver-writer-s-guide/
01:01:24 <geist> yah. a question there is whether or not anyone bothers writing UEFI byte-code drivers, or if it's all native because that's probably far easier
01:01:42 <doug16k> https://edk2-docs.gitbooks.io/edk-ii-uefi-driver-writer-s-guide/18_pci_driver_design_guidelines/187_pci_option_rom_images/README.7.html
01:01:43 <geist> how does one go about writing a byte code driver anyway? is it assumed you're writing in byte-code assembly? is there a C compiler somewhere?
01:02:36 <geist> well, this looks useful.
01:03:34 <doug16k> intel sells you a compiler
01:03:41 <geist> ah okay, this would imply that there is no such thing as a byte code driver
01:03:49 <geist> they're one or more PE formatted binaries
01:03:59 <doug16k> https://software.intel.com/en-us/system-studio
01:04:40 <doug16k> this link redirects to ^^^ -> http://software.intel.com/en-us/articles/intel-c-compiler-for-efi-byte-code-purchase/
01:05:00 <doug16k> so presumably it has a bytecode backend
01:05:27 <geist> ah okay. no yeah it's called EBC
01:06:13 <bcos> geist: PE32+ has a "machine type" field where one of the options is EFI byte-code (other options include the usual suspects - x64, IA32, MIPS16, ARM little endian, ...)
01:06:42 <geist> yah and IPF and EBC
01:06:45 <geist> where IPF is itanium
01:06:51 <geist> kk. that makes sense
01:07:52 <bcos> Ideally; I'd hope most/all (discrete) PCI devices have EFI byte-code so you can slap the same card into anything (ARM, Itanium, ...) and have it work
01:08:04 <geist> so it does stand to reason that maybe most devices to end up with EBC drivers. i guess it wouldn't make much sense to use them for the motherboard rom, unless they tend to be substantially smaller
01:08:26 <geist> right, and for example the uefi arm machine i have does have an external intel nic in it
01:08:50 <geist> and you can use it, so stands to reason that it did the right thing, unless of course there's an intel nic in the uefi rom, etc
01:09:34 <geist> being that it's i think literally an intel nic, from intel, they probably didn't include an arm64 binary in their rom
01:09:44 <geist> so if it did come from the rom on the card it came from EBC
01:10:16 <bcos> Hmm - it's nice that "ideally" actually happens sometimes :-)
01:10:33 <geist> otoh it's a few levels of conjecture, so who knows
01:10:57 <geist> that being said it doesn't look like a very performant environment: polled mode, no interrupts except for one timer, single cpu
01:13:46 <geist> i guess an interesting question is if you can poke around in the uefi shell and actually retrieve this infomation
01:14:01 <geist> or even write a PE binary that dumps it. which drivers are in use, what their format is, where the driver came from
01:17:51 <geist> also looks like it'd be possible to compile your bootloader PE image as an EBC
01:27:21 <doug16k> protection is nonexistent, should be no problem
02:39:29 <jjuran> As opposed to LR devs?
02:39:49 <jjuran> Some devs are too low-revel, and need to get out more
02:40:12 <jjuran> or so I heard
02:42:14 <doug16k> hey!!! EDID in virtio GPU
02:42:18 <doug16k> v1.1
02:43:52 <bcos> Not sure what info EDID might return for a window in host's GUI
02:45:48 <doug16k> pointless if it isn't the real thing when fullscreen
02:46:01 <doug16k> nearly pointless
02:46:09 <doug16k> could be used to implement apis that give that
02:46:40 <geist> huh. so it's populated with some stock data i guess?
02:47:13 <doug16k> I'm curious
02:48:01 <bcos> If it is fullscreen, you'd hope it'd return the actual monitor's EDID
09:47:13 <doug16k> nice, got virtio-gpu to have multiple monitors
09:47:42 <doug16k> incantation: -global driver=virtio-vga,property=max_outputs,value=2
09:48:57 <doug16k> I see the other display in spice too
01:33:19 <stisl> I have a problem with activated caching my framebuffer is superfast, but also multitasking hangs sometimes so that some tasks will be ultra-slow or freezing for multiple seconds
01:33:57 <stisl> without caching the framebuffer is horrible slow
01:34:06 <stisl> but then multitasking is much more stable
01:34:45 <stisl> what should I do?
01:36:34 * eryjus is very interested as this sounds a lot like his current problem...
01:38:10 <stisl> I think the problem was there also before, but it happend only in long time testing
01:38:26 <stisl> after a few hours
01:38:41 <stisl> now after a few seconds
01:39:31 <stisl> I think there are no shared variables by the threads, but i am not so 100% sure
01:40:03 <stisl> I am saving also the SSE2 registers in the context switch
01:40:15 <stisl> because with them copying is much faster for example
01:40:53 <stisl> the scheduler frequency is 10.000 Hz
01:41:08 <eryjus> right now, my list of problems is far longer than my list of facts for discerning what is going on. but like you I have a bug that has been around for a while as I was able to redo a test scenario and duplicate it on older versions.
01:43:29 <stisl> some kind of debugging tool for threads would be fine I think
01:44:02 <stisl> some persistent buffer which I can read after testing
01:45:17 <stisl> currently I visualize the frames per second and the irq-rate but this is also not enough maybe
01:45:51 <stisl> for a performance testcase I think it is important to read more counters
01:47:13 <stisl> the stack-usage of every thread would be nice, but for this I need another timer
01:48:15 <stisl> or maybe I should use real hardweight tasks in kernel mode
01:48:24 <stisl> and alow threads only in userspace
01:49:55 <stisl> It feels a little bit crazy when lightweight threads are running in kernelmode
01:50:14 <stisl> to much things which can go on wrong
01:50:49 <stisl> then better mmap()ing from userspace in order to connect the memory of two threads
01:51:12 <stisl> I am not sure
01:52:44 <stisl> In linux I think they also don't have currently real threads I think. When I write a kernelmodule with a thread there and don't call the scheduler it will crash
01:54:31 <stisl> which means that real threading is running in userspace
01:58:18 <stisl> I think my problem is that the framebuffer access should not be interrupted so hard
01:58:34 <stisl> maybe I can deactivate scheduling for a specific period
01:59:14 <stisl> yes, this could it be the solution I think
02:00:51 <stisl> eryjus, do you now the phenomenon (in mostly every operating systems) that If you are running multiple threads without sleeps it will crash much faster
02:02:02 <stisl> I saw people who have written a lot of sleeps in there code when there was a regression
02:02:13 <stisl> their
02:03:01 <eryjus> stisl, that sounds like masking the problem.. I would rather get to the root cause and address that.
02:08:17 <stisl> then I would say the only real chance to catch the bug is to instrument the code as much as possible
02:09:13 <stisl> for this I need some recording tool in my kernel - I don't have any harddrive drivers in
02:11:32 <stisl> in the emulator everything is working fine
02:11:47 <stisl> thats always my problem
02:12:13 <stisl> I cannot debug with the emulator because there are mostly no bugs visible
02:12:53 <stisl> everything is working fine in the damn emulator
02:15:55 <stisl> I think I will try first to turn scheduling off while accessing the framebuffer - I hope the jitter will not be increased too much then :(
02:16:14 <eryjus> stisl, afaik, most emulators will not emulate the TLB.. perhaps a place to look?
02:16:44 <stisl> in my opinion the most problems are coming with the tlb
02:17:22 <stisl> a lot of the "hobby" operating systems are running in the emulator fine but not on a real machine
02:17:37 <stisl> mostly they are crashing when sth. with the TLB is done
02:19:58 <stisl> maybe there are a lot of misunderstandings with the TLB
03:13:50 <pigworts2> Hi everybody, I have a question about RTC interrupts. I have interrupts working fine from both the PIT and keyboard, but RTC interrupts never seem to fire, despite what I put in RTC registers A and B. I've cleared the interrupt mask on the slave PIC, but it doesn't work on virtual box or QEMU.. anyone got any ideas as to why?
03:17:13 <eryjus> did you unmask irq2 on the master?
03:33:03 <pigworts2> Eryjus: why would I need to?
03:34:13 <eryjus> pigworts2, the slave PIC is wired to the master via IRQ2. let me get the wiki page
03:35:28 <eryjus> https://wiki.osdev.org/PIC#How_does_the_8259_PIC_chip_work.3F
06:11:42 <geist> hmm, it is almost assuredly not the TLB
06:11:51 <geist> but they're gone
06:32:21 <blackandblue> Why TTL (Time to live) are different for each OS ?
06:32:36 <geist> in TCP/IP?
06:32:40 <blackandblue> yup
06:32:48 <geist> good question, guess they just picked different defaults
06:32:57 <blackandblue> yea but why
06:33:07 <geist> no idea
06:33:16 <geist> you can probably set them somewhere
06:33:30 <blackandblue> really?
06:33:49 <blackandblue> https://subinsb.com/default-device-ttl-values/
06:33:54 <geist> you certainly can per socket, but i wouldn't be surprised if you couldn't set it globally somehow
06:34:15 <geist> or perhaps per route or gateway, since it has everything to do with how far a packet would need to go
06:34:28 <geist> presumably you want to set the TTL to the lowest that you need + some safety factor
06:35:08 <geist> MTU is somewhat similar: lots of stacks have different defaults for ethernet and whatnot
06:35:12 <blackandblue> I see
06:36:50 <geist> but yeah that is kinda interesting. it's fairly clear that systems that just set the TTL to 255 assume that it's not particularly useful
06:37:09 <geist> which is likely to be the case. it'd be interesting to see how often packets actually TTL expire in the 'wild'
06:37:31 <geist> it may be that it's so rare, or so non-useful that there's little point setting it to anything but 255 or some other high value
06:40:18 <blackandblue> could be
06:40:40 <blackandblue> for linux its set to 64
06:40:43 <blackandblue> by default
06:40:44 <blackandblue> :)
06:41:29 <geist> ah some of that page indicated it was set to 255. but then those entries are obviously fairly old
06:41:37 <geist> and/or it's overridden by the particular distro
06:43:40 <geist> in my random experience with pinging things from my house and whatnot, i generally haven't seen many routes go past 20 or so
06:44:01 <geist> there are probably degenerate edges, but i get the impressino that modern routing is fairly 'wide'
07:09:15 <doug16k> 255 is crazy as TTL. there will never be 200+ hops
07:09:36 <_mjg> i think windows 95 used 32
07:09:55 <_mjg> since linux had 64 i was determined to find a box which would not be reachable with lower value
07:10:04 <_mjg> at least at the time i failed
07:59:25 <doug16k> realized my non-ECAM PCI code was completely broken yesterday. gotta get a test matrix going that watches for regressions in less common cases someday
09:37:54 <pigworts2> eryjus: thanks, that worked perfectly :) (maybe i shall add it to the wiki at some point)
09:46:22 <zid> doug_16k: 255 is insane, then you release an update with it changed to 100, and you get a bunch of angry emails saying you broke someone's network setup :P
10:02:39 <Kazinsal> re: previous discussion on route length, the average BGP AS-path is 4 ASes
10:27:32 <Kazinsal> it's however a common thing to mark some paths as less preferable by prefixing your own AS path a few times so if you're unlucky and you get sent down one of those less preferable paths you might see a bunch of traffic pinging between edge routers before it hits the actual egress from an ISP
10:28:03 <Kazinsal> ISPs *supposed* to filter out long AS paths like that buuuuut sometimes it doesn't happen
10:29:47 <Kazinsal> Average AS path length visible in the Internet Routing Table: 4.4
10:29:47 <Kazinsal> Max AS path length visible: 41
10:29:47 <Kazinsal> Max AS path prepend of ASN ( 22394) 38
10:30:08 <Kazinsal> ^^ from this week's routing table report
10:42:35 <geist> Kazinsal: neat!
11:17:59 <geist> figured someone that knows how the backbone of the internet works would chime in
11:18:20 <geist> Kazinsal: is that generally becuase there isn't that many hops or is it that a lot of the backhaul is tunneled over other protocols that you dont see?
11:18:36 <zid> there's nowhere near that many hops
11:18:44 <zid> 10 each end on the isp is extreme, and a few transit hops
11:18:45 <Kazinsal> a lot of the hops are artificially generated
11:19:02 <Kazinsal> as a sort of "please don't use this path unless you REALLY have to, it's not actually as efficient as it seems"
11:19:32 <geist> ah interesting. i guess this is what i was saying when i said that routers seem pretty wide. the routing tables must be pretty huge for the backbone stuff
11:19:44 <zid> well they don't need to be, right
11:19:54 <zid> they just need to know that 128. goes left, 243. goes right
11:20:23 <zid> If they have 16 ports filled up that generally means they route to 16 networks, not 1283982392 IPs
11:20:30 <geist> sure, but if the fanout is greater than you end up with generally less hops
11:20:44 <zid> once you're a backbone you're delivering to level3, he.net and a couple others in your area or whatever and that's it
11:20:52 <zid> and eventually 'some giant telecom isp'
11:22:34 <zid> I have a couple of hops of isp, atlantic link via telia, couple of hops of isp on the other end, and that's for thousands of miles
11:22:49 <Kazinsal> as for the backbone transit proto, it's almost always IP
11:23:42 <Kazinsal> some ISPs might wrap it in MPLS inside their network but you can't cross between service providers with MPLS
11:24:17 <zid> turns out people don't actually want super high pings, so there isn't random meshy networks on the isp level
11:24:34 <zid> it's pretty much just 'continent, country, region, city, town, you'
11:24:42 <zid> onionskin
11:25:45 <Kazinsal> I've seen some weiiird stuff between ISPs
11:25:49 <Kazinsal> like L3 EVPL
11:25:54 <zid> peering agreements are dangerous beasts
11:26:07 <zid> I'd pay an extra couple of dollars for nicer peering :P
11:26:17 <zid> I don't really care if I get 500mbps or not, I care if I get 500ms
11:27:07 <Kazinsal> you probably won't get that easily with IP transit
11:27:22 <Kazinsal> you want IP/MPLS
11:27:27 <geist> yah gotta have the low pings so you can frag your enemies
11:27:29 <Kazinsal> RIP your wallet
11:27:43 <zid> There's been a couple of isps that offered 'gaming packages'
11:27:45 <geist> wearing baggy clothes and your hat on backwards, because that's what gamers do
11:27:51 <zid> with supposed better rounds for various game protocols' packets
11:27:58 <zid> routes*
11:28:32 <Kazinsal> one of the incumbent ISPs here is finally rolling out GPON everywhere
11:28:42 <Kazinsal> of course, my town is the last one in the Vancouver area to get it
11:28:46 <geist> is that like global pata pata pon?
11:28:47 <Kazinsal> so I'm still on cable
11:29:02 <zid> global penetration of noses
11:29:07 <zid> smellovision over ip
11:30:01 <zid> passive olfactory network
11:30:45 <Kazinsal> it's rad, you can get some really good internet speeds
11:32:44 <geist> == fragging your enemies
11:33:23 <zid> https://cdn.discordapp.com/attachments/417023075348119556/575827579727249420/unknown.png I honestly don't really need faster
11:33:54 <Kazinsal> I have 300/20 at home right now and I'm good with the 300 down but the 20 up is not enough
11:33:59 <Kazinsal> need me some tasty symmetry
11:34:01 <zid> yea I only have 6 up >_<
11:34:07 <zid> just barely enough to stream x264
11:34:28 <zid> but just the upload overhead from 500mbps can choke it a little
11:34:33 <geist> i have the opposite problem: 1000/1000 and the router can't quite keep up
11:34:36 <zid> it's a lot of acks
11:34:58 <Kazinsal> yeah gig symm is just way too much for most ISP routermodems
11:35:27 <geist> well, in this ase the isp modem does a fine job of keeping up but i'm using pfsense on a fairly beefy rangeley machine
11:35:30 <zid> I'm a big fan of insane buffer bloat
11:35:45 <geist> but the derpy isp router must have good HW PPPoE offload
11:36:20 <aalm> i like canadian connections:]
11:36:47 <zid> geist: my modem has hw offload but for years it was disabled :P
11:36:52 <zid> They just did the entire stack on the cpu
11:37:05 <zid> you could ddos the modems with 600kbit of packets and all sorts of nonsense
11:37:41 <geist> ya in this case one of the cores is completely pegged at around 850mbits
11:38:00 <bcos> zid: You need at least 2 connections for DDoS
11:38:02 <bcos> ;-)
11:38:04 <geist> been thinking of moving to a unifi edge router, since i have unifi everywhere else
11:38:14 <Kazinsal> my usual recommendation is some kinda edgerouter or a tower with a couple Intel NICs and OpenBSD
11:38:18 <geist> but, unclear if they'd have any better luck with gigabit pppoe
11:39:00 <geist> Kazinsal: yah in this case the pfsense box has tons of intel nics, but there's a combination of software (pfsense bing freebsd based) and the intel nic not being able to offload pppoe that nerfs it badly
11:39:30 <geist> or at least nerfs it enough that one of the cpus bottlenecks. cpu0 to be precise, since that's where all the packets are sent to via MSI
11:40:17 <Kazinsal> yeah doing pppoe in software sucks large
11:40:18 <geist> iirc, it's specifically the combiation of pppoe over the top of a vlaned eth packet that defeats the intel nic offload
11:40:56 <geist> which causes all of the packets to be dropped into the same ring, which in this case runs to cpu0
11:41:12 <geist> otherwise the nic would apparently be allowed to distribute packets across multiple rings
11:41:20 <Kazinsal> yeah the intel NIC offload for dot1q is solid but I can see it choking on that extra 8 bytes for PPPoE
11:42:01 <aalm> why pppoe is still a thing?
11:42:12 <Kazinsal> though I gotta say pppoe attached to fibre is just... eugh
11:42:22 <Kazinsal> I don't know why providers do that
11:42:26 <Kazinsal> it's terrible
11:42:47 <zid> docsis3.1 for life?
11:42:55 <aalm> haven't seen in .fi, fibre or not
11:43:18 <zid> I thought fi used tcp/reindeer
11:43:19 <Kazinsal> I know Bell hands off PPPoE
11:43:19 <geist> i looked at it. there's some sort of historical reason why they do. it basically means they're tunneling your connection directly back to the nearby office
11:43:30 <aalm> hah
11:43:47 <Kazinsal> I think because of the GPON Telus basically gives you Metro Ethernet
11:43:51 <zid> poronet
11:43:52 <geist> and in this case the fiber coming into the building/house has multiple streams going, for video and internet and whatnot
11:43:55 <Kazinsal> but they're still rolling that out here :(
11:44:23 <geist> so at the minimum there's a box that picks out whatever the framing format is on the wire and extracts it into N streams of 802.x
11:45:26 <geist> it's not that it's ideal but it does apparently provide some sort of authentication and way to establish a link directly back to the main office
11:46:06 <Kazinsal> yeah
11:46:16 <geist> there was some article i read that basically explained how it's useful. i thin kthe gist was it's not ideal but it does serve a purpose, and someone would have to invent something equivalent
11:46:39 <aalm> ic
11:46:41 <Kazinsal> yeah, the higher quality equivalent is a lot more expensive
11:46:52 <Kazinsal> and requires a lot more hardware
11:47:05 <Kazinsal> and is definitely not something you can roll out en masse to entire cities
11:47:05 <zid> docis? :P
11:47:10 <zid> docsis*
11:47:45 <Kazinsal> MPLS with centralized internet drop-off :P
11:47:47 <zid> carries auth, video, etc just fine
11:48:18 <geist> would be fascinating to see what the low level fiber transport looks like. presumably something that just tunnels the pppoe packet
11:48:43 <Kazinsal> 2.5G SONET usually
11:49:26 <Kazinsal> your 1Gbps connection is probably out of a 2.5G down / 1.25G up pool shared between 4-8 subscribers
11:50:39 <Kazinsal> can technically TDMA up to 128 ONTs on a single GPON link back to the OLT but that's a good way to never get gigabit speeds ever
11:52:09 <Kazinsal> the link from the OLT to the CO is probably either 2.5G SONET or 10GBASE-LR
11:56:55 <geist> yah it goes back to some neighborhood box
11:57:04 <geist> i think i found it one day, it's a few blocks down