# An Experimental Implementation of a Resilient Graphic Rendering Cluster
## 5 Conclusions  
This paper's intent is the dissemination of the SEE-GRID project for which our hardware was donated. In our work based upon the SEE-GRID project, we were scavenging cycles of the process time of a donated cluster which was not used in grid operation. We were presented a task that required web-front interface to a cloud-like rendering service on a cluster, since we wanted to introduce new technology to users whom we did not want to require to issue access accounts to the cluster or GRID infrastructure itself. Architecture based on interfacing POVdriver web-front service with already proven and tested with CLI GRC-client software which managed rendering on the cluster and was designed to allow such interfacing of cluster rendering power with the Persistence of Vision Ray tracing graphic software from a common web browser. We have made a stack of layered and independent provisions to make our software robust and resilient, including the use of asynchronous I/O and polling of connections, graceful restart of connections and services in GRP protocol and in an automatic restart in case of broken connections, upon a POSIX signal from Linux operating system environment, or because of a timeout, server failure, hardware malfunction, power outage, or load-shedding, making it a proof-of-concept poor man's rendering cluster infrastructure. Graceful stop and restart have been provided upon a keyboard interrupt signal, upon which the GRC-client completes current frame rendering and then stops. The state is preserved in an UnrenderedFramesPool object periodically dumped on the disk subsystem. Makefile shell script is provided to allow the graceful restart of nodes in render farms without disrupting the rendering as a whole by the implicit restart of connections on timeout. The system presents little or negligible overhead in real-life usage with complex scenes, such as 0.7% to 2.0% in test loads. The GRC-client driver does not choke on the job until a rendering speed of 1390 fps in benchmarking and bottleneck analysis, which is far beyond what is required for normal operation. Later removals of the bottlenecks in implementation have increased maximum benchmark throughput to up to 3500 fps on our 32-core cluster, which more than doubled scalability of our solution, further reducing animation frame management overhead and allowing the glue software itself to theoretically serve in a real-time rendering environment, provided that Persistence of Vision Ray tracing agent would be substituted with a rendering program that uses hardware optimizations and cluster's GPU units. Rendering options can be tunneled through an existing OPTS parameter of the RENDER command, and the existing infrastructure of uploading with MIME types and pluggable rendering software allows for such extension. Benchmarks show that the GRC overhead would be almost negligible in a scenario of rendering 30 fps or even 120 fps. The strength of our solution is not in our hardware implementation and our cluster, but in scalability and extensibility of our software based on low overhead and low performance penalty for network outages and graceful recovery from all predicted \"unpredictable\" failures. It is designed to be more robust than our environment demands, based on insights from actual graphic industry professionals renowned in the field who attended our demonstrations. We established our design with a single thought in mind--finish the job at all costs if only one render node survives and allow for a graceful restart of rendering in case it does not, possibly on new equipment, as long as the hardware that preserved previous work survives. Due to object-oriented design, it is possible to restart rendering with a different cluster and continue rendering only unrendered, unfinished frames as long as the new rendering server's rendering engine has the same semantics of the Persistence of Vision-Ray SDL language on rendering nodes in the farm.