In 2017 we developed 2 applications that exchanged data over a TCP/IP sockets using the local loopback adapter (127.0.0.1). At that time we were running this on a Dell R740 with windows server 2016 SE and we were able to get a throughput of 1.6 Gbit/s. Now in 2020 we are running the same applications on the a new Dell R740 with exactly the same specs but now running Windows server 2019 SE and we are not able to meet requirement. During the test procedure we are only getting 1.2 - 1.3 GBit/s instead of the required 1.5 GBit/s.
One application is compiled with MinGW and uses Boost 1.66, the other is an Embarcadero project and these haven't changed since 2017. Both applications enable the "fast path loopback". The installation (users, other applications, rolls, etc...) of the Dell server is the same.
Can somebody explain why the local loopback throughput has dropped this much since Windows Server 2016 SE?
We also observed that when the run the applications both applications as administrator, the throughput goes up, what can explain this?
The same test is repeated using 2 10G adapters that this resulting in a better performance than using the local loopback adapter..
Related
I was using JDBC to connect to IBM DB2 AS400 for iSeries in my Rails Application. Now it looks like I will have to move to use the ibm_db gem.
https://github.com/ibmdb/ruby-ibmdb
I attempted this with irb first and used the following in a command like:
require 'ibm_db'
conn=IBM_DB.connect("DATABASE=ABCUATDT;hostname=TEST.HERE.COM;PORT=9471;SECURITY=SSL;PROTOCOL=TCPIP;AUTHENTICATION=SERVER;UID=username;PWD=abc1234;", "", "")
This gives me the following error:
SQL30081N A communication error has been detected. Communication
protocol being used: \"SSL\". Communication API being used:
\"SOCKETS\". Location where the error was detected: \"\".
Communication function detecting the error: \"sqlccSSLSocketSetup\".
Protocol specific error code(s): \"414\"
I then try without SSL:
conn=IBM_DB.connect("DATABASE=ABCUATDT;hostname=TEST.HERE.COM;PORT=446;PROTOCOL=TCPIP;AUTHENTICATION=SERVER;UID=username;PWD=abc1234;", "", "")
SQL30082N Security processing failed with reason \"15\" (\"PROCESSING
FAILURE\"). SQLSTATE=08001 SQLCODE=-30082"
These ports and username/pw etc all work fine with JDBC, but not using the ibm_db gem.
EDIT: I tried using different ports, I know that 8471 is open for non-SSL and 9471 is open for SSL. I decided to skip SSL altogether and I started using the db2cli on my Mac OSX.
db2cli execsql -connstring "database=ABCUATDT;hostname=TEST.HERE.COM;port=8471;uid=username;pwd=abcd1234"
This just hangs and doesn't give me a prompt to write SQL:
IBM DATABASE 2 Interactive CLI Sample Program (C) COPYRIGHT
International Business Machines Corp. 1993,1996 All Rights Reserved
Licensed Materials - Property of IBM US Government Users Restricted
Rights - Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
I then tried the python library AND the DB2 CLI - both of which gave the same errors. Is there something needed to be changed at the DB2 side?
Why would it work for JDBC but not for the IBM ODBC driver?
Speak with your i administrator(s) or management team. Stackoverflow may not be not what you need right now. When asking questions, it's smart to fully detail your environment for obvious reasons, if necessary speaking with relevant persons at the client site to establish the facts before asking questions.
Find out whether there is a Db2-connect server (separate purchase) already installed on the i-series. The regular Db2-client for MAC can then communicate with CLI/ODBC via that product which does the required protocol conversions while acting as a gateway.
Find out if there is a Db2-connect server already deployed anywhere that runs on Windows/Linux/Unix that you can use (it does the required protocol conversions while acting as a gateway) once configured with connections for i-series. The regular Db2-client for MAC OS X can then use that as a gateway for CLI/ODBC to i-series.
IBM does not currently sell "IBM i access" for MAC OS X afaik, which offers the CLI/ODBC interface and does not require a Db2-connect server. That product is available for Microsoft Windows and Linux platforms. Those platforms may offer you an alternative if MAC OS X is currently unsupported.
The regular Db2-driver from IBM for MAC OS X requires for CLI/ODBC a Db2-connect server for the protocol conversions with i-series, so db2cli tool will not work without a Db2-connect gateway.
Other non IBM vendors may offer solutions in this area.
Another possibility is to use a ODBC to JDBC bridge, running on your MAC OS X, which would reroute ODBC calls to your working jdbc driver. You might research that.
I have a physical Window Server 2008 R2 machine running SQLBase 8.5 and I have no problem connecting to it. Recently I migrated this server to a virtual machine and the problem come up. Sometimes I am able to connect to the Server and sometimes not.
I can pin my Virtual Server but not able to connect to it through SQLTalk or any client application.
Is anyone having the same issue running SQLBase 8.5 on a Virtual Machine?
Thanks!
Check how many users connect at a time. SQLBase 8.5 have some limitation when maximum number of users/cilents exceedes.
Try to find whether the issue occurs when a large query is executed. If so then try to simplify it.
Check for blocking issues. Try to test its working when disabling Internet security applications\antivirus\Firewall for some time.
Check for port issues. Check the 'listenport' value of sql.ini file.
Check for SQLBaseConnection properties and cross check the parmeters like 'connection lifetime'.
SQLBase 8.5 was only ever certified up to Windows Server 2003, and is so old I'm amazed it runs at all. You should be running at least SQLBase v12 if you're on Window Server 2008.
Here is a compatibility matrix: SQLBase compatibility v6 to v12.2
So assuming your SQLBase instance is actually up and running at the time you can't connect, check the CLIENT side sql.ini , there will be an ip address e.g. .
On the CLIENT at command prompt, run: ping -t (ipaddressofserver in CLIENT sql.ini)
I have setup Coral TPU successfully as described https://coral.withgoogle.com/docs/dev-board/get-started/. I could run the demo also. I did so using a Mac computer.
Now, I want to connect Coral to windows 10 machine. On Windows machine the drivers are installed along with mdt.
mdt shell returns:
Waiting for a device...
Unable to find any devices on your local network segment.
How can I connect?
I think MDT tool doesn't support Windows 10 now.
You can connect via Serial Port and then enable SSH.
https://blog.questionable.services/article/coral-edge-tpu-windows/
Since this question was originally asked, Google has released official support for the Coral TPU on Windows.
The new edgetpu_runtime for Windows includes the drivers necessary for connecting to the Edge TPU on Windows without any of the need for working with MDT. Of note, when running inferences with the Edge TPU on Windows, it will register two USB disconnect/connect events. In the first one it is disconnecting the device so it can upload the model, and in the second it's moving it back to the normal mode to handle inferencing.
With my limited resources and to aid debugging, I am doing local testing on a client-server (game) application by running both a server and one or more clients all on my Windows 7 dev PC. Both client and server are Java applications developed through Eclipse.
Is there any easy way to introduce lag given that everything is running on the same PC... maybe 'hack' the port used or something? Or is this only possible if each application is running on a separate PC (or separate VM)?
Make a feature in the server which makes a random lag within certain time range if detected connection comes from localhost. You can then switch this feature on/off as needed.
We can't get our PLC to reliably connect with KEPServerEX (OPC).
I was wondering if anyone else here at SOF has experience working with PLC and OPC. If so do they have any tips on making a reliable connection with our OPC Server. We currently use KEPServerEX for our OPC, but if anyone knows a better program to use we are open to suggestions.
I use Kepware OPC server for MODBUS TCP, Simatic S7 and Yokogawa for more then 5 years on 4 servers in industrial environment without any problems. It was easy to set up and showed no problems during exploatation. Actually, it was so nice that we decided to not use it only when it doesn't support the device we have (which is rare, and mostly happens when I have to develop custom OPC server). Kepware OPC server is even able to use reserved PG connection for connection to Siemens PLCs (unlike Simatic OPC Server, this is good if you have limited number of connections like in CP343 LEAN version communication module). It will also save you $$$$$ if you use data from it in some historian like OsiSoft PI which charges per OPC server connections, since all Kepware OPC servers will show as single OPC server to Osisoft PI. The only thing that made me angry was that after some trial time it stopped without warning all servers (including licenced ones) when I was evaluating one new OPC server I was supposed to try out. Have you tried Kepware technical support? Have you checked your cabling? Are you aware that trial version will stop after some time?
As an alternative you can try Matrikon OPC servers. They are also very good and run without problems.