Hacker News new | past | comments | ask | show | jobs | submit | namibj's comments login

That said, the classic case of game release can be handled with a bit of P2P if the oversubscription happens late enough to have sufficiently many downloads that can share among themselves without causing congestion for others.

Just traffic shape that protocol/connection to only use a connection free share of upstream if upstream is currently close to dropping packets, and work a bit with others to get swarms to prioritize downloading from nodes close in IPv6 address space.


Depends on your peer

You and your nearest 400 neighbours plug into a non-blocking 1g port network. Find you can do 1g to your neighbours

But you need a 400g uplink (and remember to account for resilience), so you go into a switch with 40 400g ports, ok, that's 1.6tbit

Scale this up to a small town with 20,000 people and you need 20tbit of backbone to serve your residents with 1G non-blocking, very few will ever use the full 1G

Sharing bandwidth makes perfect sense. If you want uncontended (to where? Local IXP, a major IXP? One on the other side of the world?) then get a business line which gives you uncontended connectivity.


As someone in a place without pure software patents (algorithms can't be patented, but software/hardware combination systems can be), I'm willing to let US users use an overseas hosted instance instead of locally running it.

Though keeping US entities from importing copies against US patents isn't really something I could stop.


They deactivate by discharging their power supply, after which they are lacking the stored electrical energy needed to trigger the electrical detonator.

It's not fool-proof, but a lot better than chemical/mechanical mechanisms that try to go inert.


You can't just mention those ADCs without giving at least some representative specs...

How could I give specs about undocumented chips running a closed system? We know they can sample 1080p video, therefore they must have several MHz bandwidth. Should anyone manage to hack into the internal OS (which is Linux, albeit with closed drivers) and reverse engineer the basic drivers functions, we'd have a cheap platform to play with. As an example, I would explore the possibility to use their ADCs for multi band SDR applications, as the 8 input channel board costs only around $30. Unfortunately there are a lot of ifs, but if I had the skills I would at least attempt a reverse engineering on the cheaper model.

That's already plenty specs. Only thing missing is a bit more detail as to the claimed video standard over which they do 1080p.

I worked with some of them years ago and they had plain PAL/NTSC inputs which are low res, but more recent models should be all AHD compatible, which is hi res albeit still analog. The standard was created by Korean company NextChip.

https://www.nextchip.com/en/ahd/ahd.php

https://en.wikipedia.org/wiki/HDcctv

edit: just found some data about a manufacturer of high res video sampling chipsets, along with some open source software for them.

https://www.unifore.net/product-highlights/nvr-dvr-hisilicon...

https://github.com/openhisilicon


Hmmm, thanks. It seems AHD 1 is 720p30 and AHD 2 is 1080p30, but basically just plain yellow RCA jack (just, well, overclocked accordingly). Usability as SDR depends on how well the genlock can be turned off, and how well the h/v blanking can be eliminated. One of them, the NVP6114, seems to have a COLOROFF_x register and a selectable color kill mode (no Y/C separation vs. after Y/C separation). The no-separation + color kill seems to be the closest to dumb ADC, if genlock can be eliminated. AGC seems to be somewhat optional.

On Linux you can still easily go extremely slow with plain sched_yield() as there's no guarantee the thread who holds the lock will get to run, especially in numa situations due to a strong bias against migrating threads across numa boundaries. You have to use the e.g. futex API to tell the kernel what you're waiting for.

Bare spinlocks are very bad in this way, unless you have dedicated hardware threads (with SMT you can pin all but one of the threads with the remaining thread being general purpose, though you may want a way to inform the scheduler which cores to currently prefer due to their pinned tasks being more idle).


Ehhh, I feel like I have to mention that optics like a Schmidt–Väisälä camera exist, and notably have their focal plane right in the middle of the tube.

They readily go as fast as e.g. 400mm f/2.0 with 2 tame (iirc literally just spherical) optical surfaces (mirror and near-sensor plano-convex lens) and 1 more elaborate wavy surface (back side of front glass), naturally achromatic for a 20~30 MP large image circle.

Modern technology (ability to manufacture of array waveguides that act like a bundle of fiber optics, to de-flatten the sensor's focal plane) also allows making better use of objective designs that perform well in every way but field flatness.


No, they need 220V minimum....

Soooo.... TPUv4?

Yes, but the kinds that aren't on the market.

Desktop Zen3 has a chip you can point to and call Northridge, and a chip you can point to and call southbridge. They just moved the Northridge next to the 1-2 CPU chips on the CPU side of the socket. Note that laptop (APU) Zen3 uses a single chip containing CPU, GPU, and Northridge functionality.

You'll enjoy the stick with a double blade prop on each end, using sub-revolution speed control to do it's thrust vectoring. The second prop is only needed to counter torque, btw.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: