Forum Replies Created
-
Posts
-
okay . So since nothing is being used, all you are doing is running NTP against the default timeservers that chrony picks up. So even if your second VM may be on the same rack, you will achive the accuracy that NTP provides.
Network Time Protocol (NTP) can achieve accuracy <mark class=”QVRyCf”>within tens of milliseconds over the internet, and within one millisecond in local area networks (LANs) under ideal conditions</mark>. However, accuracy can be affected by several factors, including:- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
- Stratum: The higher the stratum number, the lower the accuracy. Stratum 0 devices, such as atomic and GPS clocks, are the most accurate, but they can’t be connected to via a network connection.
- Physical distance: The further the synchronizing server is from the client, the lower the accuracy
If you would like more achive more accurate measurements you can use PTP. We do have a notebook that you can use to setup PTP in your slice which would allow you to synchronize the system clocks on your VMs.
Just make sure the sites you use have the PTP capability as not all FABRIC sites use PTP.
This notbeook show how to setup PTP synchronization on your VMs. https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/public_demos/KNIT7/Tutorial1_Precision_Time_Measurements_in_FABRIC/knit7_install_PTP.ipynb
Once setup, all the system clocks on all the VMs in the slice should be in sync to the order of 10s of microseconds or better
Thats it right there. Slice keys are not automatically updated into your VMs. You hae to run a notebook to get FABRIC to push the updated slice keys to your nodes. There is a sample notebook in the jupyter_examples/fabric_examples/fablib_api/ssh_keys/ thats show the needed commands for this.
Looks like that worked at the bastion. Time to check your slice key. This is the firngerprint of the key on the VM you are trying to connect to. Please compare it with the one you are using.
SHA256:wKS8vx7URNxBun4O+oWkyUq+SPxb9HbKFgH782mh0B8
Can you please try this one more time with the verbose output. New keys are pushed out on a time interval basis. Your latest key was updated in the bastion just 2 mins ago.
Sure you can do that, but its a ssh config issue/wrong key issue, then it may not resolve the issue. GO ahead and no the new key.
Looking at the authentication logs from the bastion, your machine is present the wrong ssh key to authenticate at the bastion. From our logs the fingerprint for the key you are using is
SHA256:Oz6TG1SqPn3WXDeMmkkO+aj4sLqqgXCjScfLKc0LB2k
Where as the key registered for your account uses
SHA256:O2vzi6TM/5gF2pQaZw6IQbAD/iZt9zkkfJW8fvDlPcA (which is the SHA256 equivalent of the fingerprint you mentioned.)
So the ssh key you have is right, but what is being used by ssh is not this correct one. Please check you ssh using a -vvv to grab a verbose log of the failed attempt. That may tell us whats going on.
Do you have your latest bastion key copied on your local machine. If so, could you please provide the fingerprint the bastion key you are using ?
Can you also post your ssh_config from your machine ? From your output above looks like your ssh ke to the bastion is not right. If this key worked from jupyterhub then most likely your local ssh config may be incorrect.
@prateek. Arash is right on this. It all depends on what kinds of aplication and your experiment is. PTP is helpful when clock synchornization is needed down to a micro/milli second level between multiple nodes that may or may not be geographically distributed.
Yes there was a power outage around that time. All nodes and VM have been restored. Please try again now.
1 user thanked author for this post.
- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
