I am trying to program a virtual network on OpenFlow by OpenDaylight.
What is the difference between Neon, Fluorine-SR2, and Oxygen-SR4?
There is no major change between these releases for the OpenFlow plugin. To see exact changes you can check the release notes for every release in this link: https://docs.opendaylight.org/en/stable-fluorine/release-notes/projects/openflowplugin.html
Related
I have two Linux machines from which I make ssh connections to different hosts however I find that the client versions on these two Linux machines are OpenSSH_7.6 and OpenSSH_7.6p1. I tried to look up the differences between these two versions at https://www.openssh.com/releasenotes.html but it seems they are same version.
I would like to understand what is the difference in these two versions if any and why such nomenclature strategy.
not very difference but in 7.7p1 its change
you can check this diff in https://fossies.org/diffs/openssh/7.6p1_vs_7.7p1/
or check all change log commit in here https://fossies.org/diffs/openssh/7.6p1_vs_7.7p1/ChangeLog-diff.html
As found on https://www.openssh.com/portable.html
The portable OpenSSH follows development of the official version, but releases are not synchronized. Portable releases are marked with a 'p' (e.g. 4.0p1). The official OpenBSD source will never use the 'p' suffix, but will instead increment the version number when they hit 'stable spots' in their development.
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
I'm working on a project which uses the D2XX drivers from FTDI chip.
We are delivering the ftd2xx.dll file as part of our application. As far as I understand, the other files (e.g. ftdibus.sys) are installed on the system (at least for Windows) where the application runs. Linux is also a target for us, but let's ignore that for simplicity now.
My question is regarding the relation between these files? If, for example, I upgrade the ftd2xx.dll file delivered with our application, will users have to install the newest drivers? What if they do not?
In addition to the specific FTDI drivers, any general source of information on this area is also very welcome.
I used to work on a project that made use of FTDI's D2XX library.
There is no tight coupling between the exact version of ftd2xx.dll and ftdibus.sys. I believe the interface between ftd2xx.dll and the kernel mode driver is version independent at the basic feature level (at least since version 2.04.06 or so). There is even functions in the DLL to query DLL and driver versions respectively.
Thus, it can happen that they are 'out of sync'. I.e. ftd2xx.dll could be one from a more recent release than ftdibys.sys or vice versa. That is not a problem as such.
You are of course in complete control of the ftd2xx.dll version, but how does the driver package get installed? Is it installed as part of your application, or do you rely on the user obtaining the driver from another source? If your application has an installer, it could be an option to include FTDI's driver package in the installation. Thereby you will know which driver version is available.
What can be really tricky (and what has caused me headaches) is if there are other devices on the PC that use FTDI's chip. If such a device is supplied with media containing an older version of the driver and the user chooses to install this driver, it will simply overwrite any existing version of the driver (e.g. the version that your installer provided). This is a potential cause of regression, because FTDI has resolved a lot of bugs in the driver over the years.
If I were you, I would check the driver version at runtime and compare it to a version that is known to work (the version that you tested your application with). If the driver is older, suggest the user to upgrade it. Otherwise I would assume it is compatible.
I tried to run the Vulkan cube example after downloading the Vulkan SDK but get the following
vkEnumerateInstanceExtensionProperties failed to find the VK_KHR_surface extension.
Do you have a compatible Vulkan installable client driver (ICD) installed?
I have a Nvidia GK107M [Geforce GT 755M] graphics card.
Regarding the graphics driver, the output of
lshw -c video | grep 'configuration' is
configuration: driver=nvidia latency=0
configuration: driver=i915 latency=0
And when I see through the driver manager it shows Nvidia-352 graphics driver. Earlier I was using Nouveau display driver which I disabled thinking that it might not support Vulkan and the Nvidia driver would. But still the same thing persists.
On running .\vulkaninfo I got a message saying that vulkan instance creation failed with VK_ERROR_INCOMPATIBLE_DRIVER.
P.S: I am using the latest Vulkan SDK releases today only. I am going to try the older SDK versions. Maybe they would work.
P.P.S: I have run into a black /blank screen issue after updating Nvidia driver to 370 and rebooting.
Optimus. Well, there you have it. To quote directly from the driver package documents:
Some designs incorporating supported GPUs may not be compatible with the NVIDIA Linux driver: in particular, notebook and all-in-one desktop designs with switchable (hybrid) or Optimus graphics will not work if means to disable the integrated graphics in hardware are not available. Hardware designs will vary from manufacturer to manufacturer, so please consult with a system's manufacturer to determine whether that particular system is compatible.
So, you need to disable it (in BIOS) if possible (as it says above).
Or get updated driver from the notebook manufacturer (Well, as much chance as seeing Android update on chinatablet. If they even bother with linux support.).
Or expect exactly the kind of problems and hackery with no guaranteed success you face.
The v352 driver you have wouldn't support Vulkan. It is older than Vulkan.
Nouveau to my knowledge doesn't support Vulkan (yet) either.
There's 3 places that the Vulkan loader looks to find a Linux driver's JSON definition file:
/etc/vulkan/icd.d
/usr/share/vulkan/icd.d
And wherever you define "VK_DRIVERS_PATH" to.
If you don't have a JSON in one of those locations for your Nvidia driver that would be a problem.
Secondly, if you do have the JSON file, but it's "library_path" entry doesn't point to a valid driver, that would also not work.
Try looking for those files.
I'm trying to deploy OpenBTS with USRP B100 using UHD. When I installed GNU Radio by apt-get it installed UHD as well, but when I tried to use uhd_usrp_probe to find my usrp it didn't work. Then I uninstalled uhd with the command: "apt-get purge uhd uhd*" and GNU Radio got removed too. After this I installed uhd by the command:
apt-get install -t 'lsb release-cs' uhd from the Ettus repositories and so UHD started to work properly. So I'm in doubt if I can go on the deploy without GNU Radio. So does OpenBTS needs GNU Radio to work?
So to answer the question you ask in the last sentence: "does OpenBTS need GNURadio to work" - the answer is no. Modern OpenBTS can use UHD directly to talk to various USRP's (including the B100), and does not require GNURadio.
To provide some historical context here: OpenBTS was never built to use GNURadio for any of the signal processing portions of its internals, however, back in the day OpenBTS relied on the libusrp1/libusrp2 libraries that were present within the GNURadio repository to talk to USRP1's and USRP2's respectively. I believe this mechanism is still supported within OpenBTS, however libusrp1/libusrp2 no longer exist in modern releases of GNURadio. In addition, they can not be used to control a B100 (libusrp1 only supports the USRP1, and libusrp2 only supports the USRP2, both products that are considered rather old at this point, and the USRP2 in particular is no longer sold). Point being, the only way OpenBTS can use GNURadio is with a very old release of GNURadio (i.e. one unlikely to be installed in any modern distribution). And more to the point, it would not use GNURadio to talk to a B100.
OpenBTS comes with a very complex build and installation system, which will install most of the components it needs itself.
Your Distro's GNU Radio will not be required. Also, now that you use the correct (new) version of UHD, GNU Radio would have to be built and linked against exactly that version of UHD (and not the one that the Distro was using when it built GNU Radio).