This project contains two binaries: client and server. Running them in tandem creates a tunnel over Websocket protocol that proxies any information.
Example
Alice wants to connect to Bob's computer via SSH (port 22), but Alice is connected to Eve's Wifi, and Eve has a firewall in place that blocks port 22. In fact, Eve's firewall only lets web traffic on ports 80 and 443 go through.
Alice can ask Faythe, who has no firewall, to set up the server (from this package) on her computer:
bazel run :server
And run the client locally:
bazel run :client -- -host=faythe.com
Now, any SOCKS5 message sent to localhost:8080 will be tunneled via websockets to Faythe's computer. If Alice wants to SSH Bob now, she can simply do:
USAGE:
bazel-bin/nighthawk_client [--latency-response-header-name <string>]
[--stats-flush-interval <uint32_t>]
[--stats-sinks <string>] ...
[--no-duration] [--simple-warmup]
[--request-source <uri format>] [--label
<string>] ... [--multi-target-use-https]
[--multi-target-path <string>]
[--multi-target-endpoint <string>] ...
[--experimental-h2-use-multiple-connections]
[--nighthawk-service <uri format>]
[--jitter-uniform <duration>] [--open-loop]
[--experimental-h1-connection-reuse-strategy
<mru|lru>] [--failure-predicate <string,
uint64_t>] ... [--termination-predicate
<string, uint64_t>] ... [--trace <uri
format>] [--sequencer-idle-strategy <spin
|poll|sleep>] [--max-requests-per-connection
<uint32_t>] [--max-active-requests
<uint32_t>] [--max-pending-requests
<uint32_t>] [--transport-socket <string>]
[--tls-context <string>]
[--request-body-size <uint32_t>]
[--request-header <string>] ...
[--request-method <GET|HEAD|POST|PUT|DELETE
|CONNECT|OPTIONS|TRACE>] [--address-family
<auto|v4|v6>] [--burst-size <uint32_t>]
[--prefetch-connections] [--output-format
<json|human|yaml|dotted|fortio
|experimental_fortio_pedantic>] [-v <trace
|debug|info|warn|error|critical>]
[--concurrency <string>] [--h2] [--timeout
<uint32_t>] [--duration <uint32_t>]
[--connections <uint32_t>] [--rps
<uint32_t>] [--] [--version] [-h] <uri
format>
Where:
--latency-response-header-name <string>
Set an optional header name that will be returned in responses, whose
values will be tracked in a latency histogram if set. Can be used in
tandem with the test server's response option
"emit_previous_request_delta_in_response_header" to record elapsed
time between request arrivals. Default: ""
--stats-flush-interval <uint32_t>
Time interval (in seconds) between flushes to configured stats sinks.
Default: 5.
--stats-sinks <string> (accepted multiple times)
Stats sinks (in json or compact yaml) where Nighthawk metrics will be
flushed. This argument is intended to be specified multiple times.
Example (json): {name:"envoy.stat_sinks.statsd"
,typed_config:{"@type":"type.googleapis.com/envoy.config.metrics.v3.St
atsdSink",tcp_cluster_name:"statsd"}}
--no-duration
Request infinite execution. Note that the default failure predicates
will still be added. Mutually exclusive with --duration.
--simple-warmup
Perform a simple single warmup request (per worker) before starting
execution. Note that this will be reflected in the counters that
Nighthawk writes to the output. Default is false.
--request-source <uri format>
Remote gRPC source that will deliver to-be-replayed traffic. Each
worker will separately connect to this source. For example
grpc://127.0.0.1:8443/.
--label <string> (accepted multiple times)
Label. Allows specifying multiple labels which will be persisted in
structured output formats.
--multi-target-use-https
Use HTTPS to connect to the target endpoints. Otherwise HTTP is used.
Mutually exclusive with providing a URI.
--multi-target-path <string>
The single absolute path Nighthawk should request from each target
endpoint. Required when using --multi-target-endpoint. Mutually
exclusive with providing a URI.
--multi-target-endpoint <string> (accepted multiple times)
Target endpoint in the form IPv4:port, [IPv6]:port, or DNS:port. This
argument is intended to be specified multiple times. Nighthawk will
spread traffic across all endpoints with round robin distribution.
Mutually exclusive with providing a URI.
--experimental-h2-use-multiple-connections
Use experimental HTTP/2 pool which will use multiple connections.
WARNING: feature may be removed or changed in the future!
--nighthawk-service <uri format>
Nighthawk service uri. Example: grpc://localhost:8843/. Default is
empty.
--jitter-uniform <duration>
Add uniformly distributed absolute request-release timing jitter. For
example, to add 10 us of jitter, specify .00001s. Default is empty /
no uniform jitter.
--open-loop
Enable open loop mode. When enabled, the benchmark client will not
provide backpressure when resource limits are hit.
--experimental-h1-connection-reuse-strategy <mru|lru>
Choose picking the most recently used, or least-recently-used
connections for re-use.(default: mru). WARNING: this option is
experimental and may be removed or changed in the future!
--failure-predicate <string, uint64_t> (accepted multiple times)
Failure predicate. Allows specifying a counter name plus threshold
value for failing execution. Defaults to not tolerating error status
codes and connection errors.
--termination-predicate <string, uint64_t> (accepted multiple times)
Termination predicate. Allows specifying a counter name plus threshold
value for terminating execution.
--trace <uri format>
Trace uri. Example: zipkin://localhost:9411/api/v1/spans. Default is
empty.
--sequencer-idle-strategy <spin|poll|sleep>
Choose between using a busy spin/yield loop or have the thread poll or
sleep while waiting for the next scheduled request (default: spin).
--max-requests-per-connection <uint32_t>
Max requests per connection (default: 4294937295).
--max-active-requests <uint32_t>
The maximum allowed number of concurrently active requests. HTTP/2
only. (default: 100).
--max-pending-requests <uint32_t>
Max pending requests (default: 0, no client side queuing. Specifying
any other value will allow client-side queuing of requests).
--transport-socket <string>
Transport socket configuration in json or compact yaml. Mutually
exclusive with --tls-context. Example (json):
{name:"envoy.transport_sockets.tls"
,typed_config:{"@type":"type.googleapis.com/envoy.api.v2.auth.Upstream
TlsContext"
,common_tls_context:{tls_params:{cipher_suites:["-ALL:ECDHE-RSA-AES128
-SHA"]}}}}
--tls-context <string>
DEPRECATED, use --transport-socket instead. Tls context configuration
in json or compact yaml. Mutually exclusive with --transport-socket.
Example (json):
{common_tls_context:{tls_params:{cipher_suites:["-ALL:ECDHE-RSA-AES128
-SHA"]}}}
--request-body-size <uint32_t>
Size of the request body to send. NH will send a number of consecutive
'a' characters equal to the number specified here. (default: 0, no
data).
--request-header <string> (accepted multiple times)
Raw request headers in the format of 'name: value' pairs. This
argument may specified multiple times.
--request-method <GET|HEAD|POST|PUT|DELETE|CONNECT|OPTIONS|TRACE>
Request method used when sending requests. The default is 'GET'.
--address-family <auto|v4|v6>
Network address family preference. Possible values: [auto, v4, v6].
The default output format is 'AUTO'.
--burst-size <uint32_t>
Release requests in bursts of the specified size (default: 0).
--prefetch-connections
Use proactive connection prefetching (HTTP/1 only).
--output-format <json|human|yaml|dotted|fortio
|experimental_fortio_pedantic>
Output format. Possible values: {"json", "human", "yaml", "dotted",
"fortio", "experimental_fortio_pedantic"}. The default output format
is 'human'.
-v <trace|debug|info|warn|error|critical>, --verbosity <trace|debug
|info|warn|error|critical>
Verbosity of the output. Possible values: [trace, debug, info, warn,
error, critical]. The default level is 'info'.
--concurrency <string>
The number of concurrent event loops that should be used. Specify
'auto' to let Nighthawk leverage all vCPUs that have affinity to the
Nighthawk process. Note that increasing this results in an effective
load multiplier combined with the configured --rps and --connections
values. Default: 1.
--h2
Use HTTP/2
--timeout <uint32_t>
Connection connect timeout period in seconds. Default: 30.
--duration <uint32_t>
The number of seconds that the test should run. Default: 5. Mutually
exclusive with --no-duration.
--connections <uint32_t>
The maximum allowed number of concurrent connections per event loop.
HTTP/1 only. Default: 100.
--rps <uint32_t>
The target requests-per-second rate. Default: 5.
--, --ignore_rest
Ignores the rest of the labeled arguments following this flag.
--version
Displays version information and exits.
-h, --help
Displays usage information and exits.
<uri format>
URI to benchmark. http:// and https:// are supported, but in case of
https no certificates are validated. Provide a URI when you need to
benchmark a single endpoint. For multiple endpoints, set
--multi-target-* instead.
L7 (HTTP/HTTPS/HTTP2) performance characterization tool.
Nighthawk gRPC service
The gRPC service can be used to start a server which is able to
perform back-to-back benchmark runs upon request. The service interface
definition can be found here.
➜ bazel-bin/nighthawk_service --help
USAGE:
bazel-bin/nighthawk_service [--service <traffic-generator-service
|dummy-request-source>]
[--listener-address-file <>] [--listen
<address:port>] [--] [--version] [-h]
Where:
--service <traffic-generator-service|dummy-request-source>
Specifies which service to run. Default 'traffic-generator-service'.
--listener-address-file <>
Location where the service will write the final address:port on which
the Nighthawk grpc service listens. Default empty.
--listen <address:port>
The address:port on which the Nighthawk gRPC service should listen.
Default: 0.0.0.0:8443.
--, --ignore_rest
Ignores the rest of the labeled arguments following this flag.
--version
Displays version information and exits.
-h, --help
Displays usage information and exits.
L7 (HTTP/HTTPS/HTTP2) performance characterization tool.
Nighthawk output transformation utility
Nighthawk comes with a tool to transform its json output to its other supported output formats.
➜ bazel-bin/nighthawk_output_transform --help
USAGE:
bazel-bin/nighthawk_output_transform --output-format <json|human|yaml
|dotted|fortio
|experimental_fortio_pedantic> [--]
[--version] [-h]
Where:
--output-format <json|human|yaml|dotted|fortio
|experimental_fortio_pedantic>
(required) Output format. Possible values: {"json", "human", "yaml",
"dotted", "fortio", "experimental_fortio_pedantic"}.
--, --ignore_rest
Ignores the rest of the labeled arguments following this flag.
--version
Displays version information and exits.
-h, --help
Displays usage information and exits.
L7 (HTTP/HTTPS/HTTP2) performance characterization transformation tool.
The following is an example of a nighthawk benchmark visualized via the Fortio UI.
fortio report --data-dir ./samples/fortio_data
Accuracy and repeatability considerations when using the Nighthawk client
Processes not related to the benchmarking task at hand may add significant noise. Consider stopping any
processes that are not needed.
Be aware that power state management and CPU Frequency changes are able to introduce significant noise.
When idle, Nighthawk uses a busy loop to achieve precise timings when starting requests, which helps minimize this.
Still, consider disabling C-state changes in the system BIOS.
Be aware that CPU thermal throttling may skew results.
Consider using taskset to isolate client and server. On
machines with multiple physical CPUs there is a choice here.
You can partition client and server on the same physical processor, or
run each of them on a different physical CPU. Be aware of the latency
effects of interconnects such as QPI.
Consider disabling hyper-threading.
Consider tuning the benchmarking system for low (network) latency. You can do that manually, or install tuned and run:
As this may change boot flags, take precautions, and familiarize
yourself with the tool on systems that you don't mind breaking. For
example, running this has been observed to mess up dual-boot systems!
sudo tuned-adm profile network-latency
When using Nighthawk with concurrency > 1 or multiple
connections, workers may produce significantly different results. That
can happen because of various reasons:
Server fairness. For example, connections may end up being serviced by the same server thread, or not.
One of the clients may be unlucky and structurally spend time waiting on requests from the other(s)
being serviced due to interference of request release timings and server processing time.
Consider using separate machines for the clients and server(s).
tar -xjf AmberTools16.tar.bz2
# Configure AMBERHOME for onceexport AMBERHOME=`pwd`# Update many patch
./update_amber --update
# it will install many softwares!
./configure gnu
# It should be load!source /home/user/Software/Amber16/amber.sh
make install
# To install MPI and openmp version, do following one more time
./configure -mpi -openmp gnu
source /home/user/Software/Amber16/amber.sh
make install
如要安装CUDA:
### If you don't install nvidia driver, use following two commands#sudo apt-get purge nvidia*#reboot### If you don't want to install nvidia-toolkit in official way:
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get install nvidia-367 nvidia-367-dev
sudo apt-get install libcuda1-367 nvidia-cuda-dev nvidia-cuda-toolkit
Do you accept the previously read EULA? (accept/decline/quit): accept
You are attempting to install on an unsupported configuration. Do you wish to continue? ((y)es/(n)o) [ default is no ]: y
Install NVIDIA Accelerated Graphics Driver for Linux-x86_64 352.39? ((y)es/(n)o/(q)uit): n
Install the CUDA 7.5 Toolkit? ((y)es/(n)o/(q)uit): y
Enter Toolkit Location [ default is /usr/local/cuda-7.5 ]:
Do you want to install a symbolic link at /usr/local/cuda? ((y)es/(n)o/(q)uit): y
Install the CUDA 7.5 Samples? ((y)es/(n)o/(q)uit): y
Enter CUDA Samples Location [ default is /home/hom ]: /usr/local/cuda-7.5
Error: unsupported compiler: 5.4.0. Use --override to override this check.
Missing recommended library: libGLU.so
Error: cannot find Toolkit in /usr/local/cuda-7.5
如果有对应Ubuntu版本的deb包, 安装则是:
# If exist deb package...
sudo dpkg -i cuda-repo-<distro>_<version>_<architecture>.deb
sudo apt-get update
sudo apt-get install cuda
# Just to test whether CUDA is OK
nvcc -V
cd /usr/local/cuda/samples
sudo chown -R <username>:<usergroup> .
cd 1_Utilities/deviceQuery
make
./deviceQuery
source .bashrc加载一下后, 就可以安装CUDA版本了!
./configure -mpi -openmp -cuda gnu
source /home/user/Software/Amber16/amber.sh
make install
可能会遇到以下错误:
In file included from /usr/local/cuda/include/cuda_runtime.h:76:0,
from <command-line>:0:
/usr/local/cuda/include/host_config.h:115:2: error: #error -- unsupported GNU version! gcc versions later than 4.9 are not supported!
#error -- unsupported GNU version! gcc versions later than 4.9 are not supported!
遇到这个问题, 我修改了config.h里面PMEMD_CU_DEFINES=-DCUDA -DMPI -DMPICH_IGNORE_CXX_SEEK -D_FORCE_INLINES, 加入了后面的-D_FORCE_INLINES. 编译成功! (参考自[memcpy' was not declared in this scope (Ubuntu 16.04) ](https://github.com/opencv/opencv/issues/6500)). 在安装GROMACS时在CMakelists.txt加入set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -D_FORCE_INLINES”)`.
ERROR: You appear to be running an X server; please exit X before installing. For further details, please see the section INSTALLING THE NVIDIA DRIVER in the README available on the Linux driver download page at www.nvidia.com.
If you use PhoenixGo in your project, please consider mentioning in your README.
If you use PhoenixGo in your research, please consider citing the library as follows:
@misc{PhoenixGo2018,
author = {Qinsong Zeng and Jianchang Zhang and Zhanpeng Zeng and Yongsheng Li and Ming Chen and Sifan Liu}
title = {PhoenixGo},
year = {2018},
journal = {GitHub repository},
howpublished = {\url{https://github.com/Tencent/PhoenixGo}}
}
Building and Running
On Linux
Requirements
GCC with C++11 support
Bazel (0.19.2 is known-good)
(Optional) CUDA and cuDNN for GPU support
(Optional) TensorRT (for accelerating computation on GPU, 3.0.4 is known-good)
The following environments have also been tested by independent contributors :
here. Other versions may work, but they have not been
tested (especially for bazel).
Download and Install Bazel
Before starting, you need to download and install bazel,
see here.
For PhoenixGo, bazel (0.19.2 is known-good), read
Requirements for details.
If you have issues on how to install or start bazel, you may want
to try this all-in-one command line for easier building instead, see
FAQ question
Building PhoenixGo with Bazel
Clone the repository and configure the building:
$ git clone https://github.com/Tencent/PhoenixGo.git
$ cd PhoenixGo
$ ./configure
./configure will start the bazel configure : ask where CUDA
and TensorRT have been installed, specify them if need.
Then build with bazel:
$ bazel build //mcts:mcts_main
Dependices such as Tensorflow will be downloaded automatically.
The building process may take a long time.
Recommendation : the bazel building uses a lot of RAM,
if your building environment is lack of RAM, you may need to restart
your computer and exit other running programs to free as much RAM
as possible.
Running PhoenixGo
Download and extract the trained network:
$ wget https://github.com/Tencent/PhoenixGo/releases/download/trained-network-20b-v1/trained-network-20b-v1.tar.gz
$ tar xvzf trained-network-20b-v1.tar.gz
The PhoenixGo engine supports GTP
(Go Text Protocol),
which means it can be used with a GUI with GTP capability, such as
Sabaki.
It can also run on command-line GTP server tools like
gtp2ogs.
But PhoenixGo does not support all GTP commands, see
FAQ question.
There are 2 ways to run PhoenixGo engine
1) start.sh : easy use
Run the engine : scripts/start.sh
start.sh will automatically detect the number of GPUs, run mcts_main
with proper config file,
and write log files in directory log.
You could also use a customized config file (.conf) by running
scripts/start.sh {config_path}.
If you want to do that, see also #configure-guide.
2) mcts_main : fully control
If you want to fully control all the options of mcts_main (such
as changing log destination, or if start.sh is not compatible for your
specific use), you can run directly bazel-bin/mcts/mcts_main instead.
For a typical usage, these command line options should be added:
--gtp to enable GTP mode
--config_path=replace/with/path/to/your/config/file to specify the
path to your config file
it is also needed to edit your config file (.conf) and manually add
the full path to ckpt, see
FAQ question.
You can also change options in config file, see
#configure-guide.
for other command line options , see also
#command-line-options
for details, or run ./mcts_main --help . A copy of the --help is
provided for your convenience here
Then follow the document included in the archive : how to install
phoenixgo.pdf
note : to support special features like CUDA 10.0 or AVX512 for example,
you can build your own build for windows, see
#79
CPU-only version :
If your GPU is not compatible, or if you don't want to use a GPU, you can download this
CPU-only version (Windows),
Follow the document included in the archive : how to install
phoenixgo.pdf
Configure Guide
Here are some important options in the config file:
num_eval_threads: should equal to the number of GPUs
num_search_threads: should a bit larger than num_eval_threads * eval_batch_size
timeout_ms_per_step: how many time will used for each move
max_simulations_per_step: how many simulations(also called playouts) will do for each move
gpu_list: use which GPUs, separated by comma
model_config -> train_dir: directory where trained network stored
model_config -> checkpoint_path: use which checkpoint, get from train_dir/checkpoint if not set
model_config -> enable_tensorrt: use TensorRT or not
model_config -> tensorrt_model_path: use which TensorRT model, if enable_tensorrt
max_search_tree_size: the maximum number of tree nodes, change it depends on memory size
max_children_per_node: the maximum children of each node, change it depends on memory size
enable_background_search: pondering in opponent's time
early_stop: genmove may return before timeout_ms_per_step, if the result would not change any more
unstable_overtime: think timeout_ms_per_step * time_factor more if the result still unstable
behind_overtime: think timeout_ms_per_step * time_factor more if winrate less than act_threshold
Options for distribute mode:
enable_dist: enable distribute mode
dist_svr_addrs: ip:port of distributed workers, multiple lines, one ip:port in each line
dist_config -> timeout_ms: RPC timeout
Options for async distribute mode:
Async mode is used when there are huge number of distributed workers (more than 200),
which need too many eval threads and search threads in sync mode.
etc/mcts_async_dist.conf is an example config for 256 workers.
enable_async: enable async mode
enable_dist: enable distribute mode
dist_svr_addrs: multiple lines, comma sperated lists of ip:port for each line
num_eval_threads: should equal to number of dist_svr_addrs lines
eval_task_queue_size: tunning depend on number of distribute workers
num_search_threads: tunning depend on number of distribute workers
Read mcts/mcts_config.proto for more config options.
Command Line Options
mcts_main accept options from command line:
--config_path: path of config file
--gtp: run as a GTP engine, if disable, gen next move only
--init_moves: initial moves on the go board, for example usage, see
FAQ question
--gpu_list: override gpu_list in config file
--listen_port: work with --gtp, run gtp engine on port in TCP protocol
--allow_ip: work with --listen_port, list of client ip allowed to connect
--fork_per_request: work with --listen_port, fork for each request or not
--v: verbose log, --v=1 for turning on some debug log, --v=0 to turning off
mcts_main --help for more command line options.
A copy of the --help is provided for your convenience
here
Analysis
For analysis purpose, an easy way to display the PV (variations for
main move path) is --logtostderr --v=1 which will display the main
move path winrate and continuation of moves analyzed, see
FAQ question for details
It is also possible to analyse .sgf files using analysis tools such as :
GoReviewPartner :
an automated tool to analyse and/or review one or many .sgf files
(saved as .rsgf file). It supports PhoenixGo and other bots. See
FAQ question
for details
FAQ
You will find a lot of useful and important information, also most common
problems and errors and how to fix them
