I have two Quadro K620 NVidia video cards. I want to compress 4 H.264 streams using NVENC SDK, 2 streams per card. video is 640x 480 30 fps.
2 streams working well without any problem but It's failed when I try to encod 3 Streams.
The function nvEncOpenEncodeSessionEx return NV_ENC_ERR_OUT_OF_MEMORY error in 3th stream.
Any idea?
Thanks.
This occurs due to a licensing limitations Please read this: "Following is the difference between licensing policies staring R358 driver(s) and the previous driver(s) . In driver(s) earlier to R358 , two simultaneous encoding sessions per system were allowed irrespective of the number of non - qualified GPUs present in the system. For example, on systems with one Quadro K4000 card and two GeForce cards, only two simultaneous encode sessions could be ru n, regardless of which GPU is running the encode session. Starting R358 , the restriction of two simultaneous encoding sessions will apply only to the combined number of sessions executed on all non - qualified cards . In the example above, the application can run N simultaneous encode sessions on Quadro K4000 card (where N is defined by the encoder/memory/hardware limitations) and two sessions on both GeForce cards combined. Thus the limit on the number of simultaneous encode sessions for such a system is N + 2"
A minimum board supports more than 2 NVENC threads in parallel is a QUADRO K2000 Please see NVENC SUPPOTED GPUs
Related
I have a Gateway - Node application using the LoRa module but I don't know whether to choose the LoRa module to interface UART or SPI.
Can someone help me distinguish the difference when using these two types? Example: when I have 5 Nodes connected to Gatewway, which one should I use? and same when I have 50 Nodes.
Thanks!
A UART converts the signals to RS232 signaling(NOT VOLTAGES, You will need an additional adapter chip like the FTDI 232H) to hook up to a serial port on a computer. Speeds are usually limited to less than 400 Kilobits per second(varies based on distance and devices)
If you are connecting multiple devices to the same micro-controller(Arduino), use SPI. The connection speeds are not limited by standards. It is a bus arrangement with 4 pins (clock SCLK, input MISO, output MOSI and Slave select SS) The SCLK, MISO, MOSI are connected to all devices.To chain additional devices it requires an additional SS pin per device.
SPI is going to be faster(several (<5?)Megabits per second is not uncommon (depends on length(not greater than .3 meters), wire quality, environmental noise and device specifications) and requires less discrete components.
Since LoRa speeds max out around 300kbps, a single SPI connected gateway could theoretically handle 15 LoRa transceivers on a single gateway.
Doing 15 devices may violate local RF duty cycle restrictions resulting in fines and/or imprisonment.
Please check with your regulatory institutions prior to implementation of any solution.
I would suggest using four transceivers with external antennas each pointing in a different cardinal direction(possibly offset) at each gateway. This configuration should permit 400+(depending on usage patterns) client devices per gateway.
I am working on a hardware-embedded software project involving USB protocol. My plan is to use a USB3.0 Hub that clusters many USB2.0 isochronous devices, each requiring around 33 Mbps BW.
Now, I know that USB3 is able to enumerate up to 127 devices [1], what I'd like to know is whether this is true if I connect USB2 devices to the USB3 Hub. Can I, in theory, use the hub with 97 USB2 devices?
Also, could I utilize the entire BW (yes, only around 70% is feasible) of a USB3 port this way? The above figures add up to 5 Gbps*70% = 3.2 Gbps = 97*33Mbps.
Any help is much appreciated.
I believe there is some confusion with your understanding.
USB 3.0 hub contains 2 logical hub partitions.
1 - USB 3.0 hub
2 - USB 2.0 hub
USB 2.0 devices communicate through the USB 2.0 hub data path which has nothing to do with USB 3.0 data path. So the assumption of the bandwidth is incorrect as they are for USB 3.0 devices connected via USB 3.0 data path.
Also USB 2.0 devices will get connected via USB 2.0 lines and NOT USB 3.0 lines.
Another misconception in your question.
The speed which you mentioned i.e. 5 Gbps, that is USB 3.0 link speed.
What that means is that 2 devices over USB 3.0 link can send or receive data at 5 Gbps. Since every hub downstream port is physically a separate link, the link speed will be same for all i.e. 5 Gbps. So its speed between 2 link partners and not end to end speed.
Now when you say End to End data transfer rate, that will depend on your host controller driver architecture, your OS performance, your Hub, etc.
For Isochronous endpoints, the hub will start data transfer on service intervals for each endpoints on each port as per USB spec but you cannot be sure that End to End data transfer rate will be equally divided.
PS - You will get a lot less end to end bandwidth by the way as the link speed for USB 2.0 is 480 Mbps. :)
I am looking for a stack allowing to connect several hundred devices,
Openthread has max numbers of hopes equal 16.
Is it possible to extend that number to have 300 devices connected sequentially?
What are requirements to the chip in this case if possible or what limits the max number of connected routing devices?
The Thread Protocol Specification currently has a limit of 15 hops between routers (or 17 hops between end devices). It is not possible to connect hundreds of devices sequentially. At the same time, the Thread Protocol does connecting hundreds of end devices to each router. However, in most practical cases, the number of end devices a router supports is determined by its memory resources.
I have 1 Full Speed (12 Mbps) CDC-ACM type USB device connected directly to a High Speed (EHCI - 480 Mbps) controller on a SoC.
When there is no user-space application opening the CDC-ACM device in linux, I see a pulse which is repeated every 1 ms (SOF). Once an application (example cat) opens the CDC-ACM device, I see a lot of IN tokens (~102) between 2 SOF's from the host and the device NAKs the IN token. We are suspecting the device is busy NAKing that it hampers its operation.
Q1: Is there a way to reduce the number of IN tokens within the 1 ms interval?
Thanks
0_l_0
We want to use a unique device identifier in a Windows 8 Metro app and the recommendation is an ASHWID, documented here:
http://msdn.microsoft.com/en-us/library/windows/apps/jj553431.aspx
I'm struggling to see how this can possibly be guaranteed unique. The format includes two bytes per hardware component, of which the most uniquely identifiable are MAC address and hard disk serial number. But just two bytes for those values really doesn't seem like enough.
If the bytes used are anything other than the least significant digits (the rightmost, as a human reads them) are taken, then two identical laptops adjacent on the production line would probably have the same ASHWIDs. The MACs and drive serials would likely be adjacent.
So, I guess the crux of my question really is how many devices have to be produced with the same CPU type and memory configuration before you're likely hit a duplicate. Seems like the same sort of problem as the Birthday Paradox, so I found a calculator for that and plugged in the numbers :)
With one MAC address and one hard disk with a two-byte identifier each, you have about 4 billion permutations. Once you've allocated just 6,000 of them, it's roughly 50/50 that you've got two the same.
(go to http://jeff.aaron.ca/cgi-bin/birthday and plug in "6563" and "4294967296" for the actual calculation).
So this really doesn't seem very unique at all. Am I right in being ultra-sceptical of this identifier, or am I missing something really significant?
No, the ASHWID is not guaranteed to uniquely identify a device. At work, I've seen dozens of daily collisions where one monthly is our tolerance.
Further, the ASHWID might frequently change for the same device -- since Windows 8 will often run on laptops that might add a docking station, USB thumb-drive, or a plug-in Bluetooth adapter. The best use of the ASHWID is for verifying that a user has only installed your app to a limited number of devices, and you do that by parsing the ASHWID and selectively comparing it to previously-seen ASHWIDs from that user.
As for a unique hardware identifier, I suggest an MD5 digest of a string containing multiple components, of which some components of the ASHWID can play a part.
You might randomly generate a large number (64+ bits) and store that (eg in the registry). And of course the user's login name/ID should be unique to that user, if you want something else to include in a hash. You also need to consider what you want to do if the user clones an OS install, or replaces the HD after a drive failure.
Back in the Windows Desktop world, I used the MachineGuid registry key and the serial number of the boot device, but I'm fighting to get access to that info in a Windows Store app. If you have access, MachineGuid is in HKLM\SOFTWARE\Microsoft\Cryptography, which MS guarantees to be unique. The serial number of the boot device ::GetVolumeInformationW(::SHGetFolderPathW(~),~) will be fairly unique but only 32 bits.
From the article:
The ASHWID provides a strong binding between the app/package and the
device by representing several individual hardware characteristics. In
order to protect user privacy, the ASHWID varies from app to app.
Unless the underlying hardware has changed, two calls from the same
app will result in identical ASHWIDs. However, the ASHWID changes if
the hardware profile of the device changes, such as when the user
unplugs a USB Bluetooth adapter. The back-end cloud service can verify
the ASHWID and compare it with previously reported values. Though the
ASHWID varies, it can be parsed to detect if the variance was simply
due to a minor change such as an addition of memory to the system. The
level of tolerance for variance is up to the implementation of the
back-end cloud service.
The ASHWID is made up of 9 components:
CPU ID of the processor
Size of the memory
Serial number of the disk device
Network adapter (NIC MAC address - first instance)
Audio adapter
Docking station
Bluetooth address
Mobile broadband device ID
BIOS
CPU ID is only unique to processor model, but NIC MAC Address should be very unique. Having said that, MAC addresses can be cloned and USB NICs can be moved from device to device. So, while I guess it's possible for two devices to have the same ASHWID, it's very unlikely. What's most challenging in using this ID is the fact that hardware can change. It's up to the service to decide which parts of the ASHWID they allow to change and which parts the do not (acceptable variance). The article itself provides guidance on that.