解决Lizzie通过ssh连接katago卡顿问题

Posted 2023-03-17

参考技术A 从使用阿里云GPU云服务器运行katago开始，就发现一个问题：那就是使用sabaki通过gtp协议调用katago，非常顺畅没有任何问题。而同样的运行参数，一旦使用lizzie调用，则卡顿现象十分严重，不得不反复通过暂停、重开，来获取数据。

开始以为是带宽的问题，后来即便将带宽提高到5M也没有丝毫效果。改用AutoDL服务器后，其带宽不需要指定，同样卡顿没有改善。

前几天通过网上学习ssh的时候，看到有文章提到不同ssh服务器，客户端获取的返回数据不一样。受此启发，想到同样GPU服务器，sabaki正常而lizzie存在问题，那说明应该是客户端获取服务器数据、转换的问题。lizzie最早是针对Leelazero的，在获取katago的gtp数据时，对部分数据不识别，或者识别转换效率低，所以导致卡顿，甚至不能正常显示。

于是查看katago的配置文件，感觉应该是logToStderr参数的问题。默认值是false，为了在sabaki观战时看到AI的计算情况，我将值改为TRUE，这样gtp日志输出到sabaki终端。但这样一来，lizzie可能对大量输入数据有些不知所措了。本机还好，一旦通过ssh获取，更是应接不暇了。

果然，将logToStderr值修改为false之后，再调用lizzie，一切正常，顺利完成旧文旧局：“未完”的一局（钱宇平vs小林光一），算是开了一个好头。

SSH连接卡顿

关闭DNS反向解析。

在linux中，默认就是开启了SSH的反向DNS解析,这个会消耗大量时间，因此需要关闭。

# vi /etc/ssh/sshd_config
UseDNS=no

在配置文件中，虽然UseDNS yes是被注释的，但默认开关就是yes

2. 关闭SERVER上的GSS认证。

在authentication gssapi-with-mic有很大的可能出现问题，因此关闭GSS认证可以提高ssh连接速度。

# vi /etc/ssh/sshd_config
GSSAPIAuthentication no

注意：修改之后记得重启sshd服务
service sshd restart
备注：测试一下ssh链接卡在那个地方

[[email protected] ~]$ ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.174.149 [192.168.174.149] port 22.
debug1: Connection established.
debug1: identity file /home/xiao/.ssh/identity type -1
debug1: identity file /home/xiao/.ssh/identity-cert type -1
debug1: identity file /home/xiao/.ssh/id_rsa type -1
debug1: identity file /home/xiao/.ssh/id_rsa-cert type -1
debug1: identity file /home/xiao/.ssh/id_dsa type -1
debug1: identity file /home/xiao/.ssh/id_dsa-cert type -1
debug1: identity file /home/xiao/.ssh/id_ecdsa type -1
debug1: identity file /home/xiao/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host ‘192.168.174.149 (192.168.174.149)‘ can‘t be established.
RSA key fingerprint is 01:e2:4c:36:39:b6:5a:de:28:87:92:1d:6a:74:2a:e0.
Are you sure you want to continue connecting (yes/no)? 
Warning: Permanently added ‘192.168.174.149‘ (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address